[GRASS-dev] Makefiles: tar failure on Solaris

Hi,

looking again at
https://intevation.de/rt/webrt?serial_num=5257&display=History
it seems that we have to remove all "tar" usage from Makefiles
(as already discovered months ago).

Attached my patch suggestion to lib/symbol/. However, stuff
like this obviously remains:

/usr/bin/install: `symbol/extra/CVS' is a directory

How to get rid of that?

Markus

(attachments)

symbol_diff (984 Bytes)

Markus Neteler wrote:

looking again at
https://intevation.de/rt/webrt?serial_num=5257&display=History
it seems that we have to remove all "tar" usage from Makefiles
(as already discovered months ago).

Attached my patch suggestion to lib/symbol/. However, stuff
like this obviously remains:

/usr/bin/install: `symbol/extra/CVS' is a directory

How to get rid of that?

+ for file in symbol/demo/* ; do $(INSTALL_DATA) $$file $(ETC)/symbol/demo ; done

Several possible options:

1. Use a more specific pattern. E.g. if you know that all of the files
you want to install begin with a lower-case letter, use "[a-z]*"
instead of just "*", if the files all have specific extensions, use
the extension, etc.

2. Use "find | while", e.g.

  find symbol/demo -type f -maxdepth 1 | \
  while read file ; do $(INSTALL_DATA) "$$file" $(ETC)/symbol/demo ; done

3. Use "test -f", e.g.

  for file in symbol/demo/* ; do \
  [ -f "$$file" ] && $(INSTALL_DATA) $$file $(ETC)/symbol/demo ; \
  done

4. Enumerate the individual files, e.g.

  $(INSTALL_DATA) symbol/demo/muchomurka $(ETC)/symbol/demo
  $(INSTALL_DATA) symbol/demo/smrk $(ETC)/symbol/demo

The last one is more work, but it avoids accidentally installing files
which shouldn't be installed, e.g. backup files created by a text
editor.

--
Glynn Clements <glynn@gclements.plus.com>

Glynn Clements wrote:

4. Enumerate the individual files, e.g.

  $(INSTALL_DATA) symbol/demo/muchomurka $(ETC)/symbol/demo
  $(INSTALL_DATA) symbol/demo/smrk $(ETC)/symbol/demo

The last one is more work, but it avoids accidentally installing files
which shouldn't be installed, e.g. backup files created by a text
editor.

more work is bad.

Hamish

On Thu, Nov 16, 2006 at 02:13:23PM +0000, Glynn Clements wrote:

Markus Neteler wrote:

> looking again at
> https://intevation.de/rt/webrt?serial_num=5257&display=History
> it seems that we have to remove all "tar" usage from Makefiles
> (as already discovered months ago).
>
> Attached my patch suggestion to lib/symbol/. However, stuff
> like this obviously remains:
>
> /usr/bin/install: `symbol/extra/CVS' is a directory
>
> How to get rid of that?

> + for file in symbol/demo/* ; do $(INSTALL_DATA) $$file $(ETC)/symbol/demo ; done

Several possible options:

...

3. Use "test -f", e.g.

  for file in symbol/demo/* ; do \
  [ -f "$$file" ] && $(INSTALL_DATA) $$file $(ETC)/symbol/demo ; \
  done

I have implemented this solution now in
lib/symbol/Makefile.

Thanks for the suggestions.

Markus

Markus Neteler wrote:

> > looking again at
> > https://intevation.de/rt/webrt?serial_num=5257&display=History
> > it seems that we have to remove all "tar" usage from Makefiles
> > (as already discovered months ago).
> >
> > Attached my patch suggestion to lib/symbol/.
...
> 3. Use "test -f", e.g.
>
> for file in symbol/demo/* ; do \
> [ -f "$$file" ] && $(INSTALL_DATA) $$file $(ETC)/symbol/demo ; \
> done

I have implemented this solution now in
lib/symbol/Makefile.

simplifying to making it easier to add new symbol groups (hopefully),

would this work:

for group in basic demo extra ; do \
    for file in symbol/$$group/* ; do \
  [ -f "$$file" ] && $(INSTALL_DATA) $$file $(ETC)/symbol/$$group ; \
    done \
done

?
Hamish

Hamish wrote:

> > > looking again at
> > > https://intevation.de/rt/webrt?serial_num=5257&display=History
> > > it seems that we have to remove all "tar" usage from Makefiles
> > > (as already discovered months ago).
> > >
> > > Attached my patch suggestion to lib/symbol/.
> ...
> > 3. Use "test -f", e.g.
> >
> > for file in symbol/demo/* ; do \
> > [ -f "$$file" ] && $(INSTALL_DATA) $$file $(ETC)/symbol/demo ; \
> > done
>
> I have implemented this solution now in
> lib/symbol/Makefile.

simplifying to making it easier to add new symbol groups (hopefully),

would this work:

for group in basic demo extra ; do \
    for file in symbol/$$group/* ; do \
  [ -f "$$file" ] && $(INSTALL_DATA) $$file $(ETC)/symbol/$$group ; \
    done \
done

Yes, but it still suffers from the issue that it installs every file
in the directory; there is no way to omit individual files from
installation.

--
Glynn Clements <glynn@gclements.plus.com>

Glynn Clements wrote:

Hamish wrote:

> > > > looking again at
> > > > https://intevation.de/rt/webrt?serial_num=5257&display=History
> > > > it seems that we have to remove all "tar" usage from Makefiles
> > > > (as already discovered months ago).
> > > >
> > > > Attached my patch suggestion to lib/symbol/.
> > ...
> > > 3. Use "test -f", e.g.
> > >
> > > for file in symbol/demo/* ; do \
> > > [ -f "$$file" ] && $(INSTALL_DATA) $$file $(ETC)/symbol/demo ;
> > > \ done
> >
> > I have implemented this solution now in
> > lib/symbol/Makefile.
>
> simplifying to making it easier to add new symbol groups
> (hopefully),
>
> would this work:
>
>
> for group in basic demo extra ; do \
> for file in symbol/$$group/* ; do \
> [ -f "$$file" ] && $(INSTALL_DATA) $$file $(ETC)/symbol/$$group
> ; \
> done \
> done

Yes, but it still suffers from the issue that it installs every file
in the directory; there is no way to omit individual files from
installation.

for $GISBASE/etc/symbol/ I don't think that's a problem as it is
specifically a file repository.

Hamish

Hamish wrote:

> Yes, but it still suffers from the issue that it installs every file
> in the directory; there is no way to omit individual files from
> installation.

for $GISBASE/etc/symbol/ I don't think that's a problem as it is
specifically a file repository.

Does anything enumerate the directory contents? If so, having
extraneous files will offer choices which shouldn't be there.

BTW, filenames which begin with a dot aren't matched by the "*"
wildcard, so they aren't a problem if you just use $dir/*, but will be
if you use "find" (I think that adding "-name '*'" should solve that
issue; if it doesn't, adding "\! -name '.*'" will).

The most common cause of problems is backup files, as these are
normally based upon the original filename (e.g. (X)Emacs will back-up
"foo" as "foo~") and don't contain a leading dot. These are excluded
from CVS by default, but could end up in tarballs if they are made
from a developer's working copy rather than a fresh checkout.

Another potential issue is README files. If a module provides a switch
to list available files, you don't want invalid files showing up in
the list.

--
Glynn Clements <glynn@gclements.plus.com>

GC:

> > Yes, but it still suffers from the issue that it installs every
> > file in the directory; there is no way to omit individual files
> > from installation.

HB:

> for $GISBASE/etc/symbol/ I don't think that's a problem as it is
> specifically a file repository.

GC:

Does anything enumerate the directory contents?

e.g. icon_files() for "d.vect icon=" and rules_files() in r.colors.

these work on installed $GISBASE dirs, not source tree, so CVS/ and
friends do not exist and are not included- hence the need for Makefile
magic.

If so, having extraneous files will offer choices which shouldn't be
there.

..

The most common cause of problems is backup files, as these are
normally based upon the original filename (e.g. (X)Emacs will back-up
"foo" as "foo~") and don't contain a leading dot. These are excluded
from CVS by default, but could end up in tarballs if they are made
from a developer's working copy rather than a fresh checkout.

Another potential issue is README files. If a module provides a switch
to list available files, you don't want invalid files showing up in
the list.

yes, but extraneous files (committed emacs backups, whatever) are bugs.

README, et cetera, would (and does) go into lib/symbol/ not
lib/symbol/symbol/

My main concern is that it is set up in a way that makes it as easy as
possible for users (and devels) to add new symbols to the system. (You
can put custom icons into $MAPSET/symbol/group/, but then use is
restricted to that one location) Having to keep a Makefile in sync is
much more error prone- a noisy bug is better than a silent one.

Hamish

Hamish wrote:

GC:
> > > Yes, but it still suffers from the issue that it installs every
> > > file in the directory; there is no way to omit individual files
> > > from installation.
HB:
> > for $GISBASE/etc/symbol/ I don't think that's a problem as it is
> > specifically a file repository.
GC:
> Does anything enumerate the directory contents?

e.g. icon_files() for "d.vect icon=" and rules_files() in r.colors.

Right, the icon= option has a list of valid options generated by
scanning that directory.

> If so, having extraneous files will offer choices which shouldn't be
> there.
..
> The most common cause of problems is backup files, as these are
> normally based upon the original filename (e.g. (X)Emacs will back-up
> "foo" as "foo~") and don't contain a leading dot. These are excluded
> from CVS by default, but could end up in tarballs if they are made
> from a developer's working copy rather than a fresh checkout.
>
> Another potential issue is README files. If a module provides a switch
> to list available files, you don't want invalid files showing up in
> the list.

yes, but extraneous files (committed emacs backups, whatever) are bugs.

Having them end up in the dist.<arch> directory is a bug. Having
additional files in the source tree is part of the development
process.

Corollary: blindly copying all files from a source directory to the
destination directory is a bug.

README, et cetera, would (and does) go into lib/symbol/ not
lib/symbol/symbol/

That's fine until you start adding third-party symbol libraries with
their own READMEs and similar. If you have to keep these in an
unrelated directory because having them in the same directory
conflicts with the installation mechanism, that suggests that you got
the installation mechanism wrong.

My main concern is that it is set up in a way that makes it as easy as
possible for users (and devels) to add new symbols to the system. (You
can put custom icons into $MAPSET/symbol/group/, but then use is
restricted to that one location) Having to keep a Makefile in sync is
much more error prone- a noisy bug is better than a silent one.

One option is to check for VERSION at the beginning of the file, so
that d.vect only lists valid symbol files as options to the icon=
argument.

--
Glynn Clements <glynn@gclements.plus.com>