> "Hari" == Raja R Harinath <[EMAIL PROTECTED]> writes:
Hari> One approach would be to use $(INSTALL_HEADER) which defaults to
Hari> $(INSTALL_DATA), and allow users to specify a special installer
Hari> if they choose. Of course, it would be nice if 'install' in
Hari> fileutils could be exte
> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
Derek> Found another bug in automake's support for dependencies using
Derek> BSD's make. This one is based on the fact that BSD make
Derek> doesn't allow comments to continue on the next line using '\'.
Derek> I just hooked into the exis
> "Ville" == Ville Laurikari <[EMAIL PROTECTED]> writes:
Ville> I sometimes need to work with AIX (poor me) and noticed that
Ville> the latest version of automake has a portable dependency
Ville> tracking mechanism. It does not work with AIX cc though, and I
Ville> though fixing it myself wo
> "Ganesan" == Ganesan R <[EMAIL PROTECTED]> writes:
Ganesan> This patch mentions the fact that mentioning a directory in
Ganesan> EXTRA_DIST will also included any CVS/RCS version control
Ganesan> files. An example is given to remove these using a dist-hook
Ganesan> target.
Thanks, I checke
> "Bob" == Bob Proulx <[EMAIL PROTECTED]> writes:
Bob> After running configure I notice that an empty file "D" is left
Bob> around as trash. I investigated and and found the following.
Thanks for the investigation and clear write-up! This helped me fix
the bug (I think) quickly. Well, qui
> "Rusty" == Rusty Ballinger <[EMAIL PROTECTED]> writes:
I don't remember replying to this.
Rusty> One problem with the patch is that since the noinst_JAVA stuff
Rusty> is "noinst", there's no install-data-am dependency on
Rusty> "install-noinstJAVA" or classnoinst.stamp, so a "make install"
> "Kevin" == Kevin Ryde <[EMAIL PROTECTED]> writes:
>> I don't know when I'll fix the bug but it will definitely be before
>> the next release.
Kevin> The bandaid I'm using is below. It seems to work, but it'd be
Kevin> a mistake to assume I know what I'm doing.
I came up with a similar pa
"Derek R. Price" wrote:
> Tom Tromey wrote:
>
> > > "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
> >
> > Derek> From comp-vars.am:
> > Derek> DEFS = @DEFS@@DEFAULT_INCLUDES@
> >
> > Ok, thanks.
> > This is definitely an automake bug.
> > Your proposed fix sounds ok to me.
>
> Patch in
Tom Tromey wrote:
> > "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
>
> Derek> From comp-vars.am:
> Derek> DEFS = @DEFS@@DEFAULT_INCLUDES@
>
> Derek> Automake subs some compiler include paths into
> Derek> @DEFAULT_INCLUDES@ during the creation of Makefile.ins from
> Derek> Makefile.am
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> @if HAS_SUBDIRS@
Akim> ...
Akim> @fi HAS_SUBDIRS@
Something like this would be fine. I'd prefer `endif' instead of
`fi'. Maybe in this case the `@'s are redundant. Supporting `else'
might also be good.
Akim> * distdir.am (dist
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (%dependencies): Don't be initialize globally for
Akim> all the files, but in...
Akim> (&initialize_per_input): here.
Akim> (&depend): New.
Akim> (@phony): Replace all occurrences with the corresponding &depen
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (@clean): Remove, replaced by...
Akim> ($dependencies{'clean'}): this.
Akim> Use `&depend' instead of push'ing into @clean.
Akim> (handle_factored_dependencies): For the time being, skip 'clean'.
Akim> (do_one
> Hm, I'm in favor of having AC_ARG_PROGRAM always run. I see no use in
> having only partial support for this option across configures. In
> addition, AM_INIT_AUTOMAKE, IIRC, calls it by itself.
>
> Pavel, Alexandre, any problem with integrating AC_ARG_PROGRAM in AC_INIT?
An obvious problem is
Tom Tromey <[EMAIL PROTECTED]> writes:
> Akim, provided that the changes don't break using automake with an
> older autoconf, I trust your judgement on reviewing them.
OK, thanks.
> I still haven't looked at the --trace code.
Anyway, I think it can still change a lot. But reading it is re
Pavel Roskin <[EMAIL PROTECTED]> writes:
> Hello, Akim!
>
> > If would be *wonderful* if someone had the courage to convert
> > Automake's test suite to Autotest :(
>
> It would be wonderful if Autotest supported XFAIL in same way. We have
> tests that are known to be broken, and tests failing
"Derek R. Price" <[EMAIL PROTECTED]> writes:
> Ok, I found the link on gnu.org on how and why. You can send me the
> set allowing multiple contributions, and I need an empployer
> disclaimer.
What do you want us to sign? The FSF has recently changed its
procedure, and we are all a bit lost.
B
"Derek R. Price" <[EMAIL PROTECTED]> writes:
Hi Derek, a few more comments on the fly. I have not played with your
patch yet.
All these comments are related to the same idea: Automake must know as
less as possible about macros. It means that if needed, we have to
equip Autoconf with macros whi
17 matches
Mail list logo
