Mail Archives: djgpp-workers/1999/05/23/05:55:31
According to Eli Zaretskii:
>
> On Sat, 22 May 1999, Martin Str|mberg wrote:
>
> > Rename "config.h.in" to "config.h-in".
>
> Is this enough? Usually, there are some targets in various Makefile's
> which refer to config.h.in, and these should be changed as well.
Yes. I thouroughly tested my instructions to compile in both LFN aware
and not aware environment. But I think there were some patches to
makefile.in files in my patch.
> > (I have made changes to configure; that's as far back in the chain
> > makefile, configure, autoconf(?)
>
> They should go into configure.in.
Does configure use configure.in to regenerate itself? Or do I need to
run something else (like autoconf or whatever).
> Btw, this is simpler:
>
> TMPDIR=${TMPDIR='/tmp'}
I'm not an expert on sh syntax, but are you sure that's correct
(typo)? Isn't it "TMPDIR=${TMPDIR[ Some other character. ]'/tmp'}"?
> It is IMHO easier to use the feature than to tweak it. Simply saying
> config.h:config.h-in in the line that sets $CONFIG_HEADERS is all it
> takes. (A similar line needs to be added to the relevant rules in
> Makefile's, see above.)
Yes, but I didn't understand what was going on, so I just corrected
what was failing.
> > -#include <y.tab.h> /* use <...> so we pick it up from the build directory */
> > +#include <y-tab.h> /* use <...> so we pick it up from the build directory */
>
> I think the DJGPP port of Bison generates y_tab.[ch] by default, so it
> might be better to use the underscore instead of the dash.
It doesn't matter, as we have to specify what the output file name is
to bison (so it works on other platforms), so it can be formwarded to
the GNU maintainer.
Right,
MartinS
- Raw text -