Please unsubscribe me from this maillist...
> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
Derek> I would guess that a similar exception for mdate-sh would be
Derek> acceptable if others thought it a good idea. I don't know much
Derek> about it, but glancing through the code seems to confirm that
Derek> an exception wouldn't h
> "Harlan" == Harlan Stenn <[EMAIL PROTECTED]> writes:
Akim> Could the fact that we are using a macro for the dependency be
Akim> responsible? Harlan, what happens if you replace the macro
Akim> invocation with its value?
Harlan> This has something to do with it.
I'm satisfied that I under
> "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes:
Lars> The "comment following trailing backslash" warning ought not to
Lars> be given if the backslash is already inside a comment. Just my
Lars> .02 cents.
Alexandre Duret-Lutz supplied a patch for this, and I just checked it
in.
Tom
> "Maciej" == Maciej W Rozycki <[EMAIL PROTECTED]> writes:
Maciej> The AM_DEPENDENCIES macro invokes depcomp, so I think it's
Maciej> appropriate to copy the program whenever the macro is used as
Maciej> a part of the configure script and not only when DEP_FILES is
Maciej> non-empty.
I think
> "Maciej" == Maciej W Rozycki <[EMAIL PROTECTED]> writes:
Maciej> I'm doing cross-compiles regularly and I've never had a
Maciej> problem with `make install-strip' using install from
Maciej> fileutils. The point is cross-tools, strip included, get
Maciej> installed in ${prefix}/${target_al
> "Kevin" == Kevin Ryde <[EMAIL PROTECTED]> writes:
Kevin> I think it should create and distribute the info files
Kevin> unconditionally, but only install (or uninstall) them under
Kevin> WANT_FOO.
>> I'd prefer not to add a special case like this.
Kevin> Oh, is distributing them unconditio
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> I don't know whether Autoconf should be more robust or Automake
Pavel> should take less (or more?) hackerish approach.
Probably the former.
Pavel> Since Autoconf-2.50 has been released, it would be fair to drop
Pavel> support for
> "Peter" == Peter Eisentraut <[EMAIL PROTECTED]> writes:
Peter> Make config.status put all the configuration information into a
Peter> single makefile and have all the other makefiles include that
Peter> one. It's saved me many boring waits.
That's an interesting idea. We could even imple
This sounds familiar to me - I think I ran in to the same problem under
FreeBSD on a configure.in script that only wanted to find the X directories
(header and libs). I had to specify AC_PROG_CC to solve the problem.
H
Hello!
First of all, sorry for cross-posting, but as you will see it's hard to
decide whether Automake or Autoconf is guilty.
I have noticed Automake testsuite failures in distname.test, subobj5.test
and subobj6.test on OpenBSD 2.7 with the CVS head versions of Autoconf and
Automake.
It turns o
Martin Hollmichel writes:
> * changing a autotool file, then waiting for configure to write 1200
> makefiles.
Make config.status put all the configuration information into a single
makefile and have all the other makefiles include that one. It's saved me
many boring waits.
--
Peter Eisentraut
Well, here's why the ansi2knr stuff didn't work.
Curious that I didn't remember this. Or run across it before.
I think it must be because we've moved a lot more of the variables
into the *.am files. In the past we generated a lot of variables in
automake itself. Automake put all the variables
Tom Tromey wrote:
>
> > "Rasmus" == Rasmus Tamstorf <[EMAIL PROTECTED]> writes:
>
> Rasmus> I think the issue is that with autoconf you setup your
> Rasmus> compiler flags (debug / optimized etc) for the entire build
> Rasmus> tree when you run ./configure. However, while developing you
> Ra
Tom Tromey <[EMAIL PROTECTED]> writes:
>
> > "Kevin" == Kevin Ryde <[EMAIL PROTECTED]> writes:
>
> Kevin> I think it should create and distribute the info files
> Kevin> unconditionally, but only install (or uninstall) them under
> Kevin> WANT_FOO.
>
> I'd prefer not to add a special case li
On 23 May 2001, Tom Tromey wrote:
> > "Rasmus" == Rasmus Tamstorf <[EMAIL PROTECTED]> writes:
>
> Rasmus> I think the issue is that with autoconf you setup your
> Rasmus> compiler flags (debug / optimized etc) for the entire build
> Rasmus> tree when you run ./configure. However, while devel
> "Kevin" == Kevin Ryde <[EMAIL PROTECTED]> writes:
Kevin> Would it be easy to let info_TEXINFOS be conditionally defined?
Kevin> I think it should create and distribute the info files
Kevin> unconditionally, but only install (or uninstall) them under
Kevin> WANT_FOO.
I'd prefer not to add
> "Rasmus" == Rasmus Tamstorf <[EMAIL PROTECTED]> writes:
Rasmus> I think the issue is that with autoconf you setup your
Rasmus> compiler flags (debug / optimized etc) for the entire build
Rasmus> tree when you run ./configure. However, while developing you
Rasmus> may want 90% to be optimize
Would it be easy to let info_TEXINFOS be conditionally defined?
if WANT_FOO
info_TEXINFOS = foo.texi
endif
I think it should create and distribute the info files unconditionally,
but only install (or uninstall) them under WANT_FOO. Perhaps it'd
just be a case of splittin
On 23 May 2001, Tom Tromey wrote:
> On to your complaints.
>
> Martin> * Mixing up debug and non debug build, do both causes double
> Martin> compile time, double diskspace and x-time more RAM for the
> Martin> debugger. Imagine to need 10 GB for Openoffice debug build and
> Martin> more than 2G
> "Harlan" == Harlan Stenn <[EMAIL PROTECTED]> writes:
Harlan> While (IMO) it "did better" than autoconf for quite a few
Harlan> years, I bailed on it several years ago because it was not
Harlan> suitable (at that time) for srcdir != builddir, and that was
Harlan> something I needed Badly. T
> I'm unaware of any. There is Metaconf (the Perl thing), but in my
> experience it isn't deeply better than autoconf. It is different, but
> less well documented and with a smaller user community.
I was the metaconfig maintainer for several years.
While (IMO) it "did better" than autoconf for
> "Guido" == Guido Draheim <[EMAIL PROTECTED]> writes:
Guido> alternatives? I mean free, documented, mature, easy
Guido> alternatives to be seen?
I'm unaware of any. There is Metaconf (the Perl thing), but in my
experience it isn't deeply better than autoconf. It is different, but
less wel
> "Martin" == Martin Hollmichel <[EMAIL PROTECTED]> writes:
Before I address your points, or at least the ones I plan to address,
I thought first I would write my own critique of the auto tools.
While I do think that these tools have deep problems, I also think you
largely avoided mentioning
On Wed, May 23, 2001 at 06:49:46PM +0100, Gary V . Vaughan wrote:
> On Tuesday 22 May 2001 6:43 pm, Eric Siegerman wrote:
> > The bootstrap could be a simple shell script that makes no
> > attempt to optimize out unnecessary actions -- after all, you
> > would rarely be running it unless all the
Hi,
I see install is not used for `make install-strip' anymore. I'm not sure
if that's a good solution. Install-sh is a script and is thus much
slower. The gain is you may set the STRIPPROG environment variable. But
the gain is questionable.
I'm doing cross-compiles regularly and I've neve
Martin Hollmichel wrote:
>
> Hi all,
>
> I think the great misunderstanding is that the autotools are
> not targeting real multiplatform development, but Unix centric
> distribution of (GNU) OpenSource Software.
>
> To do real multiplatform, multitools development the autotools
> are difficult
Hi,
The current version of automake does not link/copy depcomp when invoked
with the --add-missing option even if it is required by the configure
script. The AM_DEPENDENCIES macro invokes depcomp, so I think it's
appropriate to copy the program whenever the macro is used as a part of
the confi
On Sunday 20 May 2001 6:11 pm, Tom Tromey wrote:
> > "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
>
> Gary> Cool. Do you still want 1.4-p2 in the mean while?
>
> If you think the fixes warrant it.
> We still don't know how long it will be until 1.5 :-(
My license has been revoked :-
On Tuesday 22 May 2001 6:43 pm, Eric Siegerman wrote:
> The bootstrap could be a simple shell script that makes no
> attempt to optimize out unnecessary actions -- after all, you
> would rarely be running it unless all the actions *were*
> necessary.
Like this?
http://sources.redhat.com/autoboo
Martin Hollmichel wrote:
>
> Hi all,
>
> I think the great misunderstanding is that the autotools are
> not targeting real multiplatform development, but Unix centric
> distribution of (GNU) OpenSource Software.
well, they are not restricted to the *but* IMHO. They are
just not 100% ready-made
Hi,
I've switched to autoconf-2.50.
After running "autoupdate" (it seemed like a good idea at the time), I
discovered that automake 1.4 can't find any of the Makefile.am's.
This is because autoupdate replaced the AC_OUTPUT with AC_CONFIG_FILES
in configure.in.
I think this patch fixes it, and I
This is not restricted to borland compilers, there are quite
some C-compilers on unix-systems that quite some people like
to see supported, however most of the autotools developers
do live in a quite gnu'ish/gcc'ish environment, and every now
and then, a gmake'ish/gcc pecularity slips in that wil
sorry for the excessive addressing, but this topic touches all auto-tools.
I am in the process of convincing some people to move their Borland based
source code development to proprietary free models. As you may guess, this is
an extremly difficult task, requiring more pedagogical than technical
34 matches
Mail list logo
