Re: GNU Make Extensions
* Duft Markus wrote on Tue, Dec 16, 2008 at 08:52:23AM CET: On Tue, Dec 16, 2008 at 2:48 AM, NightStrike nightstr...@gmail.com wrote: Oh, nevermind.. You're saying that make will invoke automake to check to see if Makefile.in needs to be updated. I understand, I think, what you were saying. Yeah, but how long can it take to resolve the wildcard for a given directory? If it's a few thousand files, it's done in a second or so... I don't think that the speed argument is valid in this discussion. Look at the way people work at the shell... if somebody really wants to have all .cc files for example, he/she will do ls *.cc xx and copy the list over to Makefile.am. the ls won't take forever either. If this would be done _every_ single time I call automake, I wouldn't bother. _And_: if I really want to squeeze the last bit of performance out of automake, I can still paste in the whole list, right? So for small projects this feature would be really helpful, and for others it does not disturb in any way! For what it's worth: There are a few ways to deal with this issue. If the list of files needs to be interpreted specially by Automake, as for example source files, library or program names etc., then you have basically no other choice as to regenerate Makefile.in each time anyway. So in this case you can make a rule to always update a fragment to be included in Makefile.am. This is not very efficient, and incorporating wildcard functionality into automake wouldn't make it a lot more efficient, unless the source file handling were largely rewritten, for example. OTOH, for things such as wildcards needed only for 'make install' or 'make dist', you can most likely just work around this by either: writing appropriate *-local or *-hook rules, or having a rule that updates Makefile.in upon these times, so that such wild cards are expanded (again by a suitable script) into an included fragment file. Yet another method to deal with, that helps for the latter cases, is to require GNU make, and have a GNUmakefile in the respective build directory which can include Makefile, and do extra stuff for which you need GNU make. Of course, this cannot help much in the situations where 'automake' needs to do special per-file handling. Hope that helps. Cheers, Ralf
Re: GNU Make Extensions
On Tue, 16 Dec 2008, NightStrike wrote: Not if automake flattens it when running automake. The idea was that automake would translate the wildcard into the full file list. Oh, nevermind.. You're saying that make will invoke automake to check to see if Makefile.in needs to be updated. I understand, I think, what you were saying. You have got it exactly. Automake is not the only solution. There are other solutions out there which require GNU make and are likely to be more automatic as you prefer. One of those solutions (I forget the name) is invented by the original Automake author. Bob == Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: GNU Make Extensions
Bob == Bob Friesenhahn bfrie...@simple.dallas.tx.us writes: Bob You have got it exactly. Automake is not the only solution. There Bob are other solutions out there which require GNU make and are likely to Bob be more automatic as you prefer. One of those solutions (I forget the Bob name) is invented by the original Automake author. Quagmire: http://code.google.com/p/quagmire/ Tom
Re: GNU Make Extensions
On Fri, Dec 12, 2008 at 10:34 AM, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: On Fri, 12 Dec 2008, NightStrike wrote: I thought this only occurred when maintainer mode was turned on, and that releases should be made with that turned off. Is that not how it works? Maintainer mode is optional. Regardless, when using wildcards the maintainer (i.e. you) will become frustrated with the additional delay added to 'make'. It would be similar (or identical) to autotools regenerating the project every type you execute 'make'. Not if automake flattens it when running automake. The idea was that automake would translate the wildcard into the full file list.
Re: GNU Make Extensions
On Tue, Dec 16, 2008 at 2:48 AM, NightStrike nightstr...@gmail.com wrote: On Fri, Dec 12, 2008 at 10:34 AM, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: On Fri, 12 Dec 2008, NightStrike wrote: I thought this only occurred when maintainer mode was turned on, and that releases should be made with that turned off. Is that not how it works? Maintainer mode is optional. Regardless, when using wildcards the maintainer (i.e. you) will become frustrated with the additional delay added to 'make'. It would be similar (or identical) to autotools regenerating the project every type you execute 'make'. Not if automake flattens it when running automake. The idea was that automake would translate the wildcard into the full file list. Oh, nevermind.. You're saying that make will invoke automake to check to see if Makefile.in needs to be updated. I understand, I think, what you were saying.
RE: GNU Make Extensions
On Tue, Dec 16, 2008 at 2:48 AM, NightStrike nightstr...@gmail.com wrote: On Fri, Dec 12, 2008 at 10:34 AM, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: On Fri, 12 Dec 2008, NightStrike wrote: I thought this only occurred when maintainer mode was turned on, and that releases should be made with that turned off. Is that not how it works? Maintainer mode is optional. Regardless, when using wildcards the maintainer (i.e. you) will become frustrated with the additional delay added to 'make'. It would be similar (or identical) to autotools regenerating the project every type you execute 'make'. Not if automake flattens it when running automake. The idea was that automake would translate the wildcard into the full file list. Oh, nevermind.. You're saying that make will invoke automake to check to see if Makefile.in needs to be updated. I understand, I think, what you were saying. Yeah, but how long can it take to resolve the wildcard for a given directory? If it's a few thousand files, it's done in a second or so... I don't think that the speed argument is valid in this discussion. Look at the way people work at the shell... if somebody really wants to have all .cc files for example, he/she will do ls *.cc xx and copy the list over to Makefile.am. the ls won't take forever either. If this would be done _every_ single time I call automake, I wouldn't bother. _And_: if I really want to squeeze the last bit of performance out of automake, I can still paste in the whole list, right? So for small projects this feature would be really helpful, and for others it does not disturb in any way! Cheers, Markus
Re: GNU Make Extensions
On Thu, Dec 11, 2008 at 12:04 PM, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: On Thu, 11 Dec 2008, Duft Markus wrote: There is a philosophical stance that the software we develop is intended for the software users rather than the software developer. There is a problem if build behavior is different for the user than for the software developer. Build behaviour wouldn't change, would it? Makefile.in would have the same contents as before You might notice that stark lack of interest on the list with discussing this issue since it has been discussed to death several times before. Note that normally when one types 'make' the build environment checks to see if it is up to date, and if is not up to date, then various 'auto' tools are executed to bring it up to date before any actual building starts. If the build depends on the list of files which happen to be available in a directory, then the current list of files needs to be checked and the makefiles regenerated (if necessary) before any actual building can ensue. For large projects this could take substantial time. I thought this only occurred when maintainer mode was turned on, and that releases should be made with that turned off. Is that not how it works?
Re: GNU Make Extensions
On Fri, 12 Dec 2008, NightStrike wrote: I thought this only occurred when maintainer mode was turned on, and that releases should be made with that turned off. Is that not how it works? Maintainer mode is optional. Regardless, when using wildcards the maintainer (i.e. you) will become frustrated with the additional delay added to 'make'. It would be similar (or identical) to autotools regenerating the project every type you execute 'make'. Bob == Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
RE: GNU Make Extensions
On Thu, 11 Dec 2008, Duft Markus wrote: There is a philosophical stance that the software we develop is intended for the software users rather than the software developer. There is a problem if build behavior is different for the user than for the software developer. Build behaviour wouldn't change, would it? Makefile.in would have the same contents as before You might notice that stark lack of interest on the list with discussing this issue since it has been discussed to death several times before. Note that normally when one types 'make' the build environment checks to see if it is up to date, and if is not up to date, then various 'auto' tools are executed to bring it up to date before any actual building starts. If the build depends on the list of files which happen to be available in a directory, then the current list of files needs to be checked and the makefiles regenerated (if necessary) before any actual building can ensue. For large projects this could take substantial time. Bob == Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: GNU Make Extensions
On Wed, Dec 10, 2008 at 12:39 AM, Ralf Wildenhues [EMAIL PROTECTED] wrote: Hello Tom, * Tom Browder wrote on Wed, Dec 10, 2008 at 01:38:53AM CET: Is it legal to use the += operator in lieu of \ when listing members of a variable in Makefile.am's? Yes. In this case, an Automake extension over portable make syntax, i.e., automake will flatten the += and 'make' won't ever see it. Thanks, Ralf and Bob. -Tom
Re: GNU Make Extensions
On Wed, 10 Dec 2008, Tom Browder wrote: * Tom Browder wrote on Wed, Dec 10, 2008 at 01:38:53AM CET: Is it legal to use the += operator in lieu of \ when listing members of a variable in Makefile.am's? Yes. In this case, an Automake extension over portable make syntax, i.e., automake will flatten the += and 'make' won't ever see it. I didn't really trust += in my own Automake makefiles since it was not really clear to me in what order the appending would occur and since I am also using Automake includes, the ordering might get changed in some bad way if the include order is changed. So for my makefiles I used additional variables with explicit concatenation, leaving nothing to chance. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: GNU Make Extensions
On Wed, Dec 10, 2008 at 1:39 AM, Ralf Wildenhues [EMAIL PROTECTED] wrote: Hello Tom, * Tom Browder wrote on Wed, Dec 10, 2008 at 01:38:53AM CET: Is it legal to use the += operator in lieu of \ when listing members of a variable in Makefile.am's? Yes. In this case, an Automake extension over portable make syntax, i.e., automake will flatten the += and 'make' won't ever see it. Cheers, Ralf If automake has the ability to flatten the += syntax so that non-portable make advances can be used, why can't the same logic apply to wildcard usage? The biggest argument against it that I've heard is that it is a GNU-only option. However, I've suggested in the past that it'd be great if Automake can just process the wildcard and output the Makefile.in accordingly. It sounds like my suggestion wasn't that wild afterall if Automake can do this currently for things like +=. When you have a library with 357 source files, the list in Makefile.am becomes unwieldy.
Re: GNU Make Extensions
On Wednesday 2008-12-10 16:04, Bob Friesenhahn wrote:
On Wed, 10 Dec 2008, Tom Browder wrote:
* Tom Browder wrote on Wed, Dec 10, 2008 at 01:38:53AM CET:
Is it legal to use the += operator in lieu of \ when listing
members of a variable in Makefile.am's?
Yes. In this case, an Automake extension over portable make syntax,
i.e., automake will flatten the += and 'make' won't ever see it.
I didn't really trust += in my own Automake makefiles since it was not really
clear to me in what order the appending would occur
Would it matter? Except for use of := (which I think is non-portable
too), expansion of ${variables} will happen at the latest possible
time, long after += has been parsed (linearly top-down probably).
Re: GNU Make Extensions
On Wed, 10 Dec 2008, NightStrike wrote: If automake has the ability to flatten the += syntax so that non-portable make advances can be used, why can't the same logic apply to wildcard usage? The biggest argument against it that I've heard is that it is a GNU-only option. However, I've suggested in the past that it'd be great if Automake can just process the wildcard and output the Makefile.in accordingly. It sounds like my suggestion wasn't that wild afterall if Automake can do this currently for things like +=. Automake is written in Perl, which is a very powerful scripting language. Of course it could easily be extended to do such a thing. When you have a library with 357 source files, the list in Makefile.am becomes unwieldy. I think that the fear is that the package will accidentally end up with 356 or 358 source files but that exactly 357 are required. There is the idea that software should be constructed by design rather than by accident. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: GNU Make Extensions
On Wed, 10 Dec 2008, Jan Engelhardt wrote:
I didn't really trust += in my own Automake makefiles since it was not really
clear to me in what order the appending would occur
Would it matter? Except for use of := (which I think is non-portable
too), expansion of ${variables} will happen at the latest possible
time, long after += has been parsed (linearly top-down probably).
The linearly top-down probably bit is the part that I don't trust
since in a complex project ordering can easily change. Even if the
term probably is removed, I prefer to be more explicit.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: GNU Make Extensions
On Wed, Dec 10, 2008 at 10:35 AM, Bob Friesenhahn [EMAIL PROTECTED] wrote: On Wed, 10 Dec 2008, NightStrike wrote: If automake has the ability to flatten the += syntax so that non-portable make advances can be used, why can't the same logic apply to wildcard usage? The biggest argument against it that I've heard is that it is a GNU-only option. However, I've suggested in the past that it'd be great if Automake can just process the wildcard and output the Makefile.in accordingly. It sounds like my suggestion wasn't that wild afterall if Automake can do this currently for things like +=. Automake is written in Perl, which is a very powerful scripting language. Of course it could easily be extended to do such a thing. When you have a library with 357 source files, the list in Makefile.am becomes unwieldy. I think that the fear is that the package will accidentally end up with 356 or 358 source files but that exactly 357 are required. There is the idea that software should be constructed by design rather than by accident. Shouldn't the onus be on me, as the project maintainer, to accept that risk and craft the wildcards properly? I for one would wager heavily that the probability of that being a problem is FAR less than the current problems of maintaining the source file list. Doing it manually has already proven so error-prone as to cause significant lost time. What I guess is missing here is that I am not advocating that certain desirable extensions be *required*, just that they be *available*.
Re: GNU Make Extensions
On Wed, 10 Dec 2008, NightStrike wrote: Shouldn't the onus be on me, as the project maintainer, to accept that risk and craft the wildcards properly? I for one would wager heavily that the probability of that being a problem is FAR less than the current problems of maintaining the source file list. Doing it manually has already proven so error-prone as to cause significant lost time. The problem is not so much the crafting of wildcards as it is unintended accidents in the filesystem. For my own project I do have some bits which are based on wildcards and several times files have been bundled up which I did not intend to be included. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: GNU Make Extensions
On Wed, Dec 10, 2008 at 10:57 AM, Bob Friesenhahn [EMAIL PROTECTED] wrote: On Wed, 10 Dec 2008, NightStrike wrote: Shouldn't the onus be on me, as the project maintainer, to accept that risk and craft the wildcards properly? I for one would wager heavily that the probability of that being a problem is FAR less than the current problems of maintaining the source file list. Doing it manually has already proven so error-prone as to cause significant lost time. The problem is not so much the crafting of wildcards as it is unintended accidents in the filesystem. For my own project I do have some bits which are based on wildcards and several times files have been bundled up which I did not intend to be included. Ok, so again, I should be allowed to accept that *potential* risk as being far less than the current situation of *actual* risk which is causing problems. If I knew anything about Perl, I'd just do it myself, but alas, the automake source confounds me :(
Re: GNU Make Extensions
Message: 4 Date: Wed, 10 Dec 2008 07:39:04 +0100 From: Ralf Wildenhues [EMAIL PROTECTED] Subject: Re: GNU Make Extensions To: Tom Browder [EMAIL PROTECTED] Cc: automake@gnu.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Hello Tom, * Tom Browder wrote on Wed, Dec 10, 2008 at 01:38:53AM CET: Is it legal to use the += operator in lieu of \ when listing members of a variable in Makefile.am's? Yes. In this case, an Automake extension over portable make syntax, i.e., automake will flatten the += and 'make' won't ever see it. Cheers, Ralf One caveat is that there are a few += specific issues in Automake 1.6 that can cause the operator to fail during reconf. If you have a += in a conditional section, you'll get an error along the lines of CCFILES was already defined in condition TRUE, which implies condition SOME_CONDITION. In that situation, you have to either upgrade Automake or stick to the line-continuations. Fortunately, Mac OS X 10.4 is one of the remaining (common) configurations still stuck on the ancient 1.6 version. Prior to 10.5, a couple of the autotools were actually managed as part of the core OS that isn't allowed to change between major versions. (See thread on the apple dev mailing list for details.) It was finally decoupled with 10.5, though, so it's no longer an issue. Cheers! Sean
Re: GNU Make Extensions
On Wed, 10 Dec 2008, NightStrike wrote: Ok, so again, I should be allowed to accept that *potential* risk as being far less than the current situation of *actual* risk which is causing problems. If I knew anything about Perl, I'd just do it myself, but alas, the automake source confounds me :( There is a philosophical stance that the software we develop is intended for the software users rather than the software developer. There is a problem if build behavior is different for the user than for the software developer. It seems that increasingly there is an idea among software developers and maintainers that software developer satisfaction is more important than user satisfaction. Software lasts longer than any individual maintainer or developer and so GNU build tools should strive to preserve the freedom of that software by ensuring that end users are provided with the same facilities that the original developers had available. This includes the list of files which are included in the package. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: GNU Make Extensions
Hi Bob, * Bob Friesenhahn wrote on Wed, Dec 10, 2008 at 04:04:23PM CET: On Wed, 10 Dec 2008, Tom Browder wrote: * Tom Browder wrote on Wed, Dec 10, 2008 at 01:38:53AM CET: Is it legal to use the += operator in lieu of \ when listing members of a variable in Makefile.am's? Yes. In this case, an Automake extension over portable make syntax, i.e., automake will flatten the += and 'make' won't ever see it. I didn't really trust += in my own Automake makefiles since it was not really clear to me in what order the appending would occur and since I am also using Automake includes, the ordering might get changed in some bad way if the include order is changed. So for my makefiles I used additional variables with explicit concatenation, leaving nothing to chance. With +=, the order is kept as you specify it. Even with conditionals in the loop, as in foo = a if COND foo += b else foo += c d endif foo += e There used to be issues in this area, but they have been fixed for quite some time (see NEWS if you need details). Cheers, Ralf
Re: GNU Make Extensions
* Jan Engelhardt wrote on Wed, Dec 10, 2008 at 04:32:24PM CET:
On Wednesday 2008-12-10 16:04, Bob Friesenhahn wrote:
i.e., automake will flatten the += and 'make' won't ever see it.
I didn't really trust += in my own Automake makefiles since it was not
really
clear to me in what order the appending would occur
Would it matter? Except for use of := (which I think is non-portable
too), expansion of ${variables} will happen at the latest possible
time, long after += has been parsed (linearly top-down probably).
Two issues: first, yes, the order can matter:
For example, you want to specify lib_LTLIBRARIES in the order in which
you want them installed, so that later libraries can depend on ones
listed earlier in the variable (yes, this is to work around an Automake
limitation, but that's not important for my point).
Second, with respect to late expansion, you are confusing 'automake'
and 'make' semantics. Yes, 'make' will do late expansion as you say.
However, 'automake' already needs to look at some of the values of
variables, and may take specific action upon them. This evaluation
done by 'automake' is of course done at the time 'automake' is run,
and strange things may happen if you, say, do things like
make lib_LTLIBRARIES='libsome-new-name.la'
with a library name that has not been mentioned in the Makefile.am file.
Hope that helps.
Cheers,
Ralf
Re: GNU Make Extensions
* NightStrike wrote on Wed, Dec 10, 2008 at 04:25:58PM CET: If automake has the ability to flatten the += syntax so that non-portable make advances can be used, why can't the same logic apply to wildcard usage? The biggest argument against it that I've heard is that it is a GNU-only option. The biggest arguments are listed in the FAQ entry aptly named 'wildcards'. As already mentioned elsewhere, there is another argument: semantically it seems a bad idea to let the output of 'automake' depend on arbitrary files. It already depends on configure.ac, more macro files, Makefile.am and included files, and some texinfo input files' contents, and the presence of a couple of files. The latter two items are extremely ugly I would say, if only because users tend not to be aware of this, and bugs in this area thus are harder to reproduce. I would be very hard pressed to introduce more such issues. Cheers, Ralf
Re: GNU Make Extensions
* NightStrike wrote on Wed, Dec 10, 2008 at 04:46:28PM CET: Shouldn't the onus be on me, as the project maintainer, to accept that risk and craft the wildcards properly? I for one would wager heavily that the probability of that being a problem is FAR less than the current problems of maintaining the source file list. Doing it manually has already proven so error-prone as to cause significant lost time. I don't understand. You let some script generate a fragment file that is include'd by a Makefile.am file and lists all files to be distributed or installed. The script gets run by a make rule when appropriate. Problem solved, no? The only downside I see is that you need to run automake during development, which is something many projects do anyway. Cheers, Ralf
Re: GNU Make Extensions
Bob Friesenhahn wrote: On Wed, 10 Dec 2008, NightStrike wrote: Ok, so again, I should be allowed to accept that *potential* risk as being far less than the current situation of *actual* risk which is causing problems. If I knew anything about Perl, I'd just do it myself, but alas, the automake source confounds me :( There is a philosophical stance that the software we develop is intended for the software users rather than the software developer. There is a problem if build behavior is different for the user than for the software developer. It seems that increasingly there is an idea among software developers and maintainers that software developer satisfaction is more important than user satisfaction. Damn right there is, or i'd just be developing for Redmond. Only with low development agro will developers be more motivated to fix users problems. If that wasn't the case, i'd be programming in assembler. Software lasts longer than any individual maintainer or developer and so GNU build tools should strive to preserve the freedom of that software by ensuring that end users are provided with the same facilities that the original developers had available. This includes the list of files which are included in the package.
RE: GNU Make Extensions
On Wed, 10 Dec 2008, NightStrike wrote: Ok, so again, I should be allowed to accept that *potential* risk as being far less than the current situation of *actual* risk which is causing problems. If I knew anything about Perl, I'd just do it myself, but alas, the automake source confounds me :( There is a philosophical stance that the software we develop is intended for the software users rather than the software developer. There is a problem if build behavior is different for the user than for the software developer. Build behaviour wouldn't change, would it? Makefile.in would have the same contents as before It seems that increasingly there is an idea among software developers and maintainers that software developer satisfaction is more important than user satisfaction. This is not an idea of software developers only. Of course, I also like to have a convenient way to work on my packages (which is the reason I prefer to use Confix [1], which wraps autotools, and does work with wildcards, and this works quite well), but the main problem is, that when developing commercial software (or even open source software in a commercial environment, just as I do), my boss won't accept, that it takes hours to maintain the *build*. Come on - this just can't be true. For me it takes a few *seconds* to bootstrap a new package from just source files to a complete autotools manages package, without too many problems. In the developer case - hell yeah - our time is precious too, not only user satisfaction counts! Also thinking this a little further: especially when I'm working at home on some free software, I have sometimes only half an hour or something like that to spend on developing; I *don't* want to spend this time maintaining the build mechanism!! Really: I don't want to do this. If I would not have Confix [1] I wouldn't use autotools... Software lasts longer than any individual maintainer or developer and so GNU build tools should strive to preserve the freedom of that software by ensuring that end users are provided with the same facilities that the original developers had available. This includes the list of files which are included in the package. Oh, come on. This is simply invalid. The list of files is used to create a distfile, so the list of files is the files included in the distfile. It can *always* be reconstructed, and if you're looking for some *special* list of files, which is wildcarded in makefile.am, then either simply 'ls' with the same wildcard in the directory, or look into makefile.in, since this has to conatin the flattened list of files anyway... Sorry if this sounds a little rude, it's not meant to be. It's just that about the same discussion is around at our company for some years now, forcing us to slowly move away from autotools (can you imagine the amout of work to move ~700 libraries to another build system?!?) Cheers, Markus Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
RE: GNU Make Extensions
[snip] Also thinking this a little further: especially when I'm working at home on some free software, I have sometimes only half an hour or something like that to spend on developing; I *don't* want to spend this time maintaining the build mechanism!! Really: I don't want to do this. If I would not have Confix [1] I wouldn't use autotools... Sorry, forgot the link ;) [1] http://confix.sf.net Software lasts longer than any individual maintainer or developer and so GNU build tools should strive to preserve the freedom of that software by ensuring that end users are provided with the same facilities that the original developers had available. This includes the list of files which are included in the package. [snip] Cheers, Markus Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: GNU Make Extensions
Hello Tom, * Tom Browder wrote on Wed, Dec 10, 2008 at 01:38:53AM CET: Is it legal to use the += operator in lieu of \ when listing members of a variable in Makefile.am's? Yes. In this case, an Automake extension over portable make syntax, i.e., automake will flatten the += and 'make' won't ever see it. Cheers, Ralf
