On 11 Sep 2000, Akim Demaille wrote:

> 
> |     Let me take the example of a2ps.  a2ps uses a configuration file which
> |     is installed in syscondir.  To find it the path is hard coded in a2ps,
> |     and a natural means to do that would be
> | 
> |     AC_DEFINE_UNQUOTED([A2PS_CONFIG_FILE], ["$sysconfdir/a2ps.cfg"])
> | 
> | The natural way to implement it and follow the spec is to pass the
> | value of the sysconfdir Make variable to gcc as the expansion of a
> | macro, so that compilation will put it into the program.  The Make
> | variable's default value could be set up in Makefile by Autoconf;
> | that would make --sysconfdir work.
> 
> Yes, thank you, I know this.  This is what I do.  But pardon me, this
> is by no means something I consider ``natural''.  

Ditto.  

And remember: doing this for shell scripts at build time is even LESS
"natural".


> |     We are asking for the removal of this feature (i.e., that the sequence
> |     above is considered right).
> | 
> | Sorry, I will not do this.  People use it and it is easy to implement.
> 
> Who is using it, and for what purpose?
> 
> And it is definitely not easy to implement, I strongly disagree.
> 
> I'm ready to endure strict standards once I understand them.  So
> please, tell me why you want that there are two different means to say
> the same thing?  Why do you want both
> 
>         ./configure --prefix=/foo
>         make
> 
> and
> 
>         ./configure
>         make prefix=/foo
> 
> ?
> 
> If the Makefile must support this feature, why should configure accept
> --prefix?
> 
> 
> The problem can be summarized as: ``I don't understand the point of
> this part the standards''.

Akim is not the only one.  For example, we ran into these difficulties
when autoconfiscating fvwm.


To expand on Akim's penultimate question, what should happen in the case
that the builder changes his mind:

        ./configure
        make prefix=/foo
        make prefix=/bar

?

Should the pathnames, hardcoded using -DDATADIR=$datadir, use the first
prefix or the second?  

If the first, then what is the harm in requiring it to be set at configure
time?

If the second, then how do you implement this properly?  It would seem (to
me) to require that the program is rebuilt *every time* you run make, just
in case the person changed their mind.  But then 

        make 
        make install prefix=/tmp/bla

would put the wrong pathnames into the executable.

-S



Reply via email to