From: Martin Str|mberg <ams AT ludd DOT luth DOT se>
Message-Id: <199905230955.LAA12331@father.ludd.luth.se>
Subject: Re: Bash 2.03 final beta available
To: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
Date: Sun, 23 May 1999 11:55:15 +0200 (MET DST)
Cc: djgpp-workers AT delorie DOT com (DJGPP-WORKERS)
In-Reply-To: <Pine.SUN.3.91.990523122237.26578F-100000@is> from Eli Zaretskii at "May 23, 99 12:23:27 pm"
X-Mailer: ELM [version 2.4ME+ PL15 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

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