On Jun 26, 2000, DEMAILLE Akim <[EMAIL PROTECTED]> wrote:
> (Cygnus') Configure (I think its name is exactly Configure, and I
> will keep this capitalization to distinguish it from Autoconf's
> product, configure).
Nope, the real name is `configure', and, to the best of my knowledge,
it pre-date
Hi Alexandre,
Thanks for having spent some time to summarize the situation. When a
topic is beaten to death like this, we really need some summaries from
time to time.
Before anwering, let me recall a few constraint we face with Autoconf
(I know you, Alexandre, know them fairly well).
Basicall
Is there an Autoconf macro to filter (remove) a regex from the value of
a macro? For instance, removing -g or -O[0-9]* from the value of
CFLAGS.
Thanks,
Eric.
On Jun 26, 2000, Earnie Boyd <[EMAIL PROTECTED]> wrote:
> However, as Akim has said before, it would be bugward compatible.
My suggestion is both backward- (or bugward, if you will) and
forward-compatible. I don't understand the reason of so much heat
about it. It's a 5-lines change that give
--- Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Jun 26, 2000, Earnie Boyd <[EMAIL PROTECTED]> wrote:
>
> > I must say that I like the --host=cross-compile change.
>
> Even if you explicitly specify the same triplet for --build and
> --host? Don't you find this totally counter-intuitive? Wo
On Jun 26, 2000, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> On 26 Jun 2000, Alexandre Oliva wrote:
>> > What about a new option --xhost=TRIPLE?
>>
>> I like it. That seems exactly what Akim has been looking for:
>> something that the user can specify to not leave any doubt that cross
>> comp
On Jun 26, 2000, Earnie Boyd <[EMAIL PROTECTED]> wrote:
> I must say that I like the --host=cross-compile change.
Even if you explicitly specify the same triplet for --build and
--host? Don't you find this totally counter-intuitive? Wouldn't you
expect `configure' to figure out you're not doin
On 26 Jun 2000, Alexandre Oliva wrote:
> > What about a new option --xhost=TRIPLE?
>
> I like it. That seems exactly what Akim has been looking for:
> something that the user can specify to not leave any doubt that cross
> compilation is to take place.
Isn't that equivalent to the --cross opti
--- Mo DeJong <[EMAIL PROTECTED]> wrote:
> On 26 Jun 2000, Alexandre Oliva wrote:
>
> > > I don't buy that: nobody will never change anything in their scripts,
> >
> > If they won't change their scripts, then it's their fault. By warning
> > in advance, we're exempting ourselves from being blam
On Jun 26, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> On 26 Jun 2000, Alexandre Oliva wrote:
>> > I don't buy that: nobody will never change anything in their scripts,
>>
>> If they won't change their scripts, then it's their fault. By warning
>> in advance, we're exempting ourselves from bei
On 26 Jun 2000, Alexandre Oliva wrote:
> > I don't buy that: nobody will never change anything in their scripts,
>
> If they won't change their scripts, then it's their fault. By warning
> in advance, we're exempting ourselves from being blamed for the change.
That is an interesting point. Fol
On Jun 26, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> On 26 Jun 2000, Alexandre Oliva wrote:
>> On Jun 26, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>> > --cygnus assume program is part of Cygnus-style tree
>>
>> I've never seen this option, and it doesn't seem to be accepted by any
On 26 Jun 2000, Alexandre Oliva wrote:
> On Jun 26, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>
> > I thought there was already a switch for cygnus behavior.
>
> > --cygnus assume program is part of Cygnus-style tree
>
> I've never seen this option, and it doesn't seem to be accepted
On Jun 26, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> Worse yet, Alexandre seems to believe we should do several small
> incompatible changes
Nope. I'm proposing a backward-compatible change that warns about
behavior that's going to change in the future, and also accepts the
new behavior,
On Jun 26, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> In this case, I don't think anyone would really expect
> --build=FOO --host=FOO to do a cross compile.
Agreed
> I thought there was already a switch for cygnus behavior.
> --cygnus assume program is part of Cygnus-style tree
I'v
On Jun 26, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> And btw, do you mean host_alias != build_alias, or really build !=
> host?
_alias, i.e., what the user specifies in the command line. So he's in
full control.
> | IMO, we should take smaller steps in the right direction. Since we're
On Jun 26, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> On 26 Jun 2000, Alexandre Oliva wrote:
>> We might also set cross_compiling=maybe if --host is specified but
>> --build isn't, and then use the original cross_compiling test to
>> decide.
> But the old cross compile test did not work on sys
I can bootstrap and configure libtool now!
% ./bootstrap
tests/Makefile.am:12: warning: automake does not support conditional
definition
of CXX_TESTS in TESTS
autoheader: config.h.in is unchanged
configure.in: 33: `AM_PROG_LIBTOOL' is obsolete, use `AC_PROG_LIBTOOL'
instead
configure.in: 10: `
On Jun 26, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On Jun 26, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>>> On 26 Jun 2000, Alexandre Oliva wrote:
Here's a patch that implements my proposal regarding the han
> "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes:
Mo> How about another option? Why don't we just skip a 2.5 release and
Mo> call it 3.0?
Just do that, and tomorrow there are several new Autoconves here and
there :) I no longer think there will ever be a new major release.
We have to live wi
On 26 Jun 2000, Akim Demaille wrote:
>
> | On Jun 19, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> | > I'm sorry, but I disagree. The only sane and simple definition of
> | > cross-compilation is when --host is specified.
> |
> | It might be simple, but I'm not sure it's sane. If host and
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On Jun 26, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>> On 26 Jun 2000, Alexandre Oliva wrote:
>>> Here's a patch that implements my proposal regarding the handling
>>> of --build/--host options, assuming that Mo's patch
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> In 06-actions-ac-cache-val:
>> +[ifelse(regexp([AC_DEFINE], [$2]), [-1],
Alexandre> Oops, the arguments for regexp are reversed.
Arg, thanks. I'm fixing this.
| I tried using the new autoheader with gcc and got this error.
| cd ../../egcs/gcc && autoheader
| /usr/local/project/install/autotools/bin/autoheader: N: No such file or
| directory
Could you track this `N'? Running sh -x autoheader -d should help.
Thanks!
On 26 Jun 2000, Alexandre Oliva wrote:
> We might also set cross_compiling=maybe if --host is specified but
> --build isn't, and then use the original cross_compiling test to
> decide.
But the old cross compile test did not work on systems where
rld did not know how to find a lib the compiler li
| On Jun 19, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
| > I'm sorry, but I disagree. The only sane and simple definition of
| > cross-compilation is when --host is specified.
|
| It might be simple, but I'm not sure it's sane. If host and build are
| identical, it doesn't make sense to a
On Jun 26, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> configure.in:36: /usr/bin/m4: Bad regular expression: `# These are sane
> defaults
> that work on at least a few old systems.
In 06-actions-ac-cache-val:
> +[ifelse(regexp([AC_DEFINE], [$2]), [-1],
Oops, the arguments for regexp are rev
On Jun 26, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> On 26 Jun 2000, Alexandre Oliva wrote:
>> Here's a patch that implements my proposal regarding the handling of
>> --build/--host options, assuming that Mo's patch makes it. Ok to
>> install?
> So to do a cross build I would need to give bo
On 26 Jun 2000, Alexandre Oliva wrote:
> Here's a patch that implements my proposal regarding the handling of
> --build/--host options, assuming that Mo's patch makes it. Ok to
> install?
So to do a cross build I would need to give both --build and
--host?
Could there at least be some sort of
I tried to use the latest CVS version of autoconf with the
current CVS version of libtool, and it looks like something
got broken.
libtool ml branch with autoconf from the 25th.
cd libtool
./bootstrap
tests/Makefile.am:12: warning: automake does not support conditional
definition
of CXX_TESTS
On Jun 16, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> There is a case where the new behavior is clearly wrong.
> That is when --build and --host are both given and they
> are exactly the same. I have appended a patch to
> fix that problem.
The patch is ok with me.
--
Alexandre Oliva Enjoy
On Jun 19, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> I'm sorry, but I disagree. The only sane and simple definition of
> cross-compilation is when --host is specified.
It might be simple, but I'm not sure it's sane. If host and build are
identical, it doesn't make sense to assume we're
On Jun 26, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> + * acgeneral.m4 (AC_CONFIG_LINKS, AC_CONFIG_HEADERS,
> + AC_CONFIG_COMMANDS, AC_CONFIG_FILES): Use a shell variable instead
> + of an m4 variable to store what must be done, so that sh
> + conditionals are honored.
> +
On Jun 26, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> + * doc/autoconf.texi (Prerequisite Macros): More about AC_REQUIRE.
Ok
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student
I tried using the new autoheader with gcc and got this error.
cd ../../egcs/gcc && autoheader
/usr/local/project/install/autotools/bin/autoheader: N: No such file or
directory
autoheader: No template for symbol `HAVE_LONG_DOUBLE'
make[1]: *** [../../egcs/gcc/cstamp-h.in] Error 1
make[1]: Leaving
On Jun 26, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> + Given better names to the diversions.
Ok
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@
On Jun 26, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> + A macro which is not defined with AC_DEFUN should not be
> + AC_REQUIRE'd, since it does AC_PROVIDE itself.
Ok
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer
On Jun 26, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> + * acgeneral.m4 (AC_PRO, AC_EPI): Rename as _AC_DEFUN_PRO and
> + _AC_DEFUN_EPI.
> + Adjust dependencies.
> + (AC_DEFUN): Remove the not-to-be-released specializing mechanism.
> + (AC_SPECIALIZE): Remove for the same
On Jun 26, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> + * acgeneral.m4: Document this implementation.
> + (_AC_DEFUN_PRO, _AC_DEFUN_EPI, AC_REQUIRE): Be sure that macros
> + are emitted in the same order as they are expanded.
> + (AC_REQUIRE): Forbid being calling out of an
| So, here's the "fix". However, this is not very robust, and the real
| problem with the AC_REQUIRE diversions needs to be fixed.
The patch is in the queue.
> "Mike" == Mike Castle <[EMAIL PROTECTED]> writes:
Mike> So, the non-option method of specifying the build system is no
Mike> longer supported?
It is, but only to help you during the transition, you are encouraged
not to use it.
Mike> If so, I'd have to say, this kinda sucks.
Agreed, it s
This patch makes official the support of shell variables, and explains
why it is better not to :)
Index: 0.352/ChangeLog
--- 0.352/ChangeLog Sat, 24 Jun 2000 21:45:42 +0200 akim (ace/34_ChangeLog 1.319 666)
+++ 0.352(w)/ChangeLog Sat, 24 Jun 2000 22:48:47 +0200 akim (ace/34_ChangeLog 1.319
+666
Index: 0.351/ChangeLog
--- 0.351/ChangeLog Sat, 24 Jun 2000 21:44:31 +0200 akim (ace/34_ChangeLog 1.318 666)
+++ 0.351(w)/ChangeLog Sat, 24 Jun 2000 21:44:36 +0200 akim (ace/34_ChangeLog 1.318
+666)
@@ -5,6 +5,10 @@
2000-06-24 Akim Demaille <[EMAIL PROTECTED]>
+ * doc/autoconf.texi
Index: 0.349/ChangeLog
--- 0.349/ChangeLog Sat, 24 Jun 2000 20:07:50 +0200 akim (ace/34_ChangeLog 1.316 666)
+++ 0.349(w)/ChangeLog Sat, 24 Jun 2000 20:28:00 +0200 akim (ace/34_ChangeLog 1.316
+666)
@@ -1,5 +1,15 @@
2000-06-24 Akim Demaille <[EMAIL PROTECTED]>
+ Given better names to
Index: 0.347/ChangeLog
--- 0.347/ChangeLog Thu, 22 Jun 2000 20:50:08 +0200 akim (ace/34_ChangeLog 1.314 666)
+++ 0.347(w)/ChangeLog Thu, 22 Jun 2000 20:52:43 +0200 akim (ace/34_ChangeLog 1.314
+666)
@@ -1,3 +1,11 @@
+2000-06-22 Akim Demaille <[EMAIL PROTECTED]>
+
+ A macro which is not d
Index: 0.348/ChangeLog
--- 0.348/ChangeLog Thu, 22 Jun 2000 20:53:11 +0200 akim (ace/34_ChangeLog 1.315 666)
+++ 0.348(w)/ChangeLog Sat, 24 Jun 2000 20:05:43 +0200 akim (ace/34_ChangeLog 1.315
+666)
@@ -1,3 +1,26 @@
+2000-06-24 Akim Demaille <[EMAIL PROTECTED]>
+
+ The current implementa
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> I'm working on it at home, Monday I should bring something which
Akim> should be close to a solution + explanation :)
So I think the four next patches will solve your problem. Well, I
hope so :(
Those patches are based on a soluti
47 matches
Mail list logo
