Re: zack's todo list

["Joseph S. Myers" <jsm28 at cam dot ac dot uk>]

On Tue, 14 Nov 2000, Zack Weinberg wrote:

> static const char a[] = "blah";
> static const char b[] = "blah";
>
> - must a and b be different?  The embedded people would surely like
>   them to be merged.

I see nothing to suggest that separately declared objects, or a declared
object and an unnamed object, can be merged; whereas there is explicit
wording in 6.4.5p6 to permit string literals to merge, and in 6.5.2.5p8 to
permit compound literals with const-qualified types to merge with each
other and with string literals.

> > and a desirable feature would be DESTDIR support;
>
> I don't know what this is.

	configure --prefix=/usr
	...
	make install DESTDIR=/some/where

should install under /some/where/usr (and a packaging system is presumed
then to handle getting the software into /usr on the system where the
final install is made).  This should be less fragile, especially if more
paths than just --prefix are specified to configure, than changing prefix
at make install time.  (The name DESTDIR is the convention automake uses
in makefiles it generates, and seems to be the most common convention.
glibc calls it install_root and there are other names around.)

> > and I was thinking of also installing under version-numbered
> > names (gcc-3.0, etc.) to encourage keeping old drivers around rather than
> > trying to use -V and complaining when it doesn't work
>
> Probably a good idea.  Should we do this for all the drivers or just
> gcc itself?  Maybe we should get rid of -V and -b while we're at it?

Once we know why gcc gets the i686-pc-linux-gnu-gcc link and g77 doesn't,
for example, perhaps it would be a bit clearer when version links should
be applied.  I'd say it should apply for all drivers and any other
programs where having the right version rather than the latest version is
important - so not for gcov, for example, since gcov data files have a
standard format that doesn't depend on the version or architecture.

-- 
Joseph S. Myers
jsm28@cam.ac.uk