Alexandre Oliva [EMAIL PROTECTED] writes:
On Feb 6, 2001, Akim Demaille [EMAIL PROTECTED] wrote:
Don't go that way! AC_PREREQ.
It won't let you define fallbacks for older releases, which is exactly
the point. ifdef, as you proposed, is the way to go.
I think there is some confusion
Hello, Akim!
Under this condition, I will definitely quit the group. I'm OK with
providing reasonable backward compatibility, but I'm tired (to remain
somewhat polite) of wasting my time in details of the past.
You are missing the point completely. Nobody is asking _you_ to care about
I'd like to also work out a naming scheme for internally generated
targets. That way eventually it will be clear what people can rely
on and what they cannot. Suggestions here are welcome.
Alexandre How 'bout `_am-target-name'? (note the leading underscore)
Sounds good.
I've updated
"Pavel" == Pavel Roskin [EMAIL PROTECTED] writes:
Pavel I believe that names beginning with am_ are
Pavel private. I.e. AM_INCLUDE should become am_include. I believe
Pavel that user code should not do anything with the names beginning
Pavel with ac_ and am_.
I chose `_am_' instead to make it
Hello, Tom!
What if instead we decide on a permanent naming scheme for automake
internal variables? Then we can start moving towards that over time,
starting here.
What if instead we use `_AM_'? Or `_am_'?
After another consideration I decided that AM_INCLUDE is not meant to be
private
Pavel Roskin [EMAIL PROTECTED] writes:
Tom, you should also know you can have a special exception, and tell
autoconf AM_INCLUDE is OK. But I agree with Pavel it looks way too
much like a macro name, in itself it is confusing.
As far as I know, it cannot be done without breaking
"Pavel" == Pavel Roskin [EMAIL PROTECTED] writes:
Pavel After another consideration I decided that AM_INCLUDE is not
Pavel meant to be private since it appears in AC_SUBST.
But it is meant to be private. It is an implementation detail. If we
change the implementation it might just go away --
On Feb 6, 2001, Akim Demaille [EMAIL PROTECTED] wrote:
Don't go that way! AC_PREREQ.
It won't let you define fallbacks for older releases, which is exactly
the point. ifdef, as you proposed, is the way to go.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red
On Feb 5, 2001, Tom Tromey [EMAIL PROTECTED] wrote:
I'd like to also work out a naming scheme for internally generated
targets. That way eventually it will be clear what people can rely on
and what they cannot. Suggestions here are welcome.
How 'bout `_am-target-name'? (note the leading
Hello, Tom!
I see that you are not using the latest and greatest Autoconf.
Names beginning with AM_ are reserved for macros. Autoconf-2.49c will not
allow such names in configure.
That's why many tests are failing again - AM_INCLUDE is not a good name
for a variable.
How about renaming
Tom, you should also know you can have a special exception, and tell
autoconf AM_INCLUDE is OK. But I agree with Pavel it looks way too
much like a macro name, in itself it is confusing.
As far as I know, it cannot be done without breaking compatibility with
Autoconf 2.13.
Too bad Autoconf
"Pavel" == Pavel Roskin [EMAIL PROTECTED] writes:
Pavel I see that you are not using the latest and greatest Autoconf.
Nope.
Pavel Names beginning with AM_ are reserved for
Pavel macros. Autoconf-2.49c will not allow such names in configure.
Hmm.
Pavel That's why many tests are failing
Hello, Tom!
Pavel How about renaming AM_INCLUDE to AMINCLUDE everywhere? The
Pavel patch is attached. It fixes all tests.
My approach was too formal. AM_INCLUDE is a variable, but the names of
variables shouldn't contain any capital letters. My fault.
What if instead we decide on a
13 matches
Mail list logo
