> "Steven" == Steven G Johnson <[EMAIL PROTECTED]> writes:
Steven> Great, now that you have confirmed that it works, hopefully it
Steven> can get accepted and applied.
Given that it's a bug fix, that the solution is proposed is clearly
right, I'll apply it.
Steven> It would be nice to have
| Following the suggestions in the manual, I create a rule like
| GNUmakefile: GNUmakefile.in $(top_builddir)/config.status
| cd $(top_builddir) && CONFIG_FILES=$@ CONFIG_HEADERS= ./config.status
|
| to automatically rebuild the makefiles. The above won't work in a
| subdirectory, so how
| > + ../autoupdate -m .. -
| > c:/djgpp/tmp/au16317/input.m4:44: c:/djgpp/bin/m4.exe: Cannot open
| > [c:/djgpp/tmp/au16317/m4.m4]: No such file or directory (ENOENT)
| > c:/djgpp/tmp/au16317/input.m4:44: c:/djgpp/bin/m4.exe: Cannot open
|
| After playing with generated temporary files, it se
| Akim Demaille writes:
| > I think Autoconf should advocate a single approach.
|
| Yup.
|
| > Also, is `HAVE_WORKING_FOO' the right naming scheme? Is it powerful
| > enough to allow us the specify the various brokenness that this or
| > that function may have? Should HAVE_WORKING_FOO alway
On 9 Jun 2000, Akim Demaille wrote:
> Steven> It would be nice to have a better understanding of the
> Steven> exec/eval interaction that caused the bug before, however,
> Steven> even though my patch removes that business entirely.
>
> Agreed. Maybe one cannot understand without having a strong
> I don't get it at all. Why would you have such problems, and I
> don't???
The problem went away after the latest cvs update. I still get one failure,
but I see nothing as of yet that would classify it as DOS-specific.
=
./debug-98.sh: Testing autoupdate
=
On Fri, Jun 09, 2000 at 02:57:21AM +0200, Peter Eisentraut wrote:
> I'd find it *immensely* helpful if configure also looked for a config.site
> (or an equivalent file of different name) in the current directory.
How about config.pkg? This file will contain options specific to
a particular packa
