|
From: Robert W. <rj...@du...> - 2005-01-26 19:08:24
|
I just tried building Valgrind for the folks here at work on our FC1 machine. The build fell over because FC1 doesn't ship with autoconf 2.59, which Valgrind apparently needs. I can't install that version of autoconf very easily on this machine because it's also used as one of our product build machines and we don't want to change the system software. BTW: this appears to be a relatively new requirement - I built a version of FC1 back in December without any problems. I'm of the opinion that we should be trying to make our autoconf stuff as simple as possible to avoid situations like this. Maybe by choosing a baseline version (perhaps the version that ships with the earliest distribution release that we support) and not using any macros that don't exist in that version? Or shipping any extra macros above this that we need. Thoughts? |
|
From: Yuri <yu...@ts...> - 2005-01-26 19:25:43
|
Robert Walsh wrote: >(skip) > > >I'm of the opinion that we should be trying to make our autoconf stuff >as simple as possible to avoid situations like this. Maybe by choosing >a baseline version (perhaps the version that ships with the earliest >distribution release that we support) and not using any macros that >don't exist in that version? Or shipping any extra macros above this >that we need. > >Thoughts? > > Isn't autoconf designed that way that only resulting configure script should be shipped and used by the installing party? Configure is designed to be as portrable as possible, not autoconf. Yuri -- excerpt from "info autoconf -- > Autoconf is a tool for producing shell scripts that automatically > configure software source code packages to adapt to many kinds of > UNIX-like systems. The configuration scripts produced by Autoconf are > independent of Autoconf when they are run, so their users do not need > to have Autoconf. -- end excerpt -- |
|
From: Bryan O'S. <bo...@se...> - 2005-01-26 19:30:45
|
On Wed, 2005-01-26 at 11:25 -0800, Yuri wrote: > Isn't autoconf designed that way that only resulting configure script > should be shipped and used > by the installing party? Configure is designed to be as portrable as > possible, not autoconf. The problem is that for CVS developers, configure isn't checked into the tree (which is appropriate). Thus you need to have the appropriate version of autoconf to even build the CVS head. <b |
|
From: Jeremy F. <je...@go...> - 2005-01-26 21:55:49
|
On Wed, 2005-01-26 at 11:08 -0800, Robert Walsh wrote: > I'm of the opinion that we should be trying to make our autoconf stuff > as simple as possible to avoid situations like this. Maybe by choosing > a baseline version (perhaps the version that ships with the earliest > distribution release that we support) and not using any macros that > don't exist in that version? Or shipping any extra macros above this > that we need. I think that's when I used AS_HELP_STRING for the --with[out]-pie option. I was just following the manual; I didn't realize it would cause a compatibility problem. If dropping that is all it takes to get old autoconfs working, then we should. Or is it more complex than that? [ It's irritating that the autoconf docs don't say when various features were introduced, and which ones will cause backwards-compatibility problems. But I guess that's why I have 2 versions of autoconf and 6 versions of automake installed. ] J |
|
From: Nicholas N. <nj...@ca...> - 2005-01-26 22:40:42
|
On Wed, 26 Jan 2005, Jeremy Fitzhardinge wrote: > I think that's when I used AS_HELP_STRING for the --with[out]-pie > option. I was just following the manual; I didn't realize it would > cause a compatibility problem. If dropping that is all it takes to get > old autoconfs working, then we should. That sounds right to me. N |
|
From: Nicholas N. <nj...@ca...> - 2005-01-28 19:21:56
|
On Wed, 26 Jan 2005, Robert Walsh wrote: > I just tried building Valgrind for the folks here at work on our FC1 > machine. The build fell over because FC1 doesn't ship with autoconf > 2.59, which Valgrind apparently needs. I can't install that version of > autoconf very easily on this machine because it's also used as one of > our product build machines and we don't want to change the system > software. > > BTW: this appears to be a relatively new requirement - I built a version > of FC1 back in December without any problems. > > I'm of the opinion that we should be trying to make our autoconf stuff > as simple as possible to avoid situations like this. Maybe by choosing > a baseline version (perhaps the version that ships with the earliest > distribution release that we support) and not using any macros that > don't exist in that version? Or shipping any extra macros above this > that we need. This sounds good to me. N |
|
From: Robert W. <rj...@du...> - 2005-01-28 20:09:23
|
> > I'm of the opinion that we should be trying to make our autoconf stuff > > as simple as possible to avoid situations like this. Maybe by choosing > > a baseline version (perhaps the version that ships with the earliest > > distribution release that we support) and not using any macros that > > don't exist in that version? Or shipping any extra macros above this > > that we need. > > This sounds good to me. This was the bit where I was hoping someone would just in and say "I'll do it! I know everything about autoconf!" ;-) I guess I'll take a look over the weekend and see what I can see... Regards, Robert. |
|
From: Nicholas N. <nj...@ca...> - 2005-01-28 20:25:41
|
On Fri, 28 Jan 2005, Robert Walsh wrote:
>>> I'm of the opinion that we should be trying to make our autoconf stuff
>>> as simple as possible to avoid situations like this. Maybe by choosing
>>> a baseline version (perhaps the version that ships with the earliest
>>> distribution release that we support) and not using any macros that
>>> don't exist in that version? Or shipping any extra macros above this
>>> that we need.
>>
>> This sounds good to me.
>
> This was the bit where I was hoping someone would just in and say "I'll
> do it! I know everything about autoconf!" ;-) I guess I'll take a look
> over the weekend and see what I can see...
Is there much to do? I guess:
- decide on an acceptable maximal version
- remove the REQUIRE_VERSION(2.59) macro (or whatever it's called)
- remove any macros that don't work in the chosen maximal version
(was it AS_HELP_STRING? I think it just concatenates the program name
to a string, so replace eg:
AS_HELP_STRING("foo")
with
"valgrind: foo"
or similar)
From then on it's a matter of policy (ie. don't use new macros), rather
than coding, no?
N
|