Re: Do not create conditional installation directories
Ralf Wildenhues wrote: * Ralf Corsepius wrote on Tue, Mar 17, 2009 at 12:08:44PM CET: Allan Caffee wrote: On Sun, 15 Mar 2009, Ralf Wildenhues wrote: There is another downside: up to now, one could use something like foo_DATA = to let $(DESTDIR)$(foodir) be created at installation time. This of course no longer works, and as such is a backward incompatibility. Was this ever a documented feature? No as far as I know. I don't recall, but I know it is widely used and therefore will cause silent incompatibilities between the next automake version and its predecessors. To me personally, it's a severe functional regression. Well, here we have an item where one's bug is another person's feature. Right, and you are throwing away a _useful_ feature, pushing around users. BTW, a 'make distcheck' or a 'make install' into a fresh prefix should be able to uncover this incompatibility, so while it is silent, it is not the most silent thing there is. But the question remains: how do you think we should address the bug that bothers Akim, other than by this patch and a big warning in NEWS? IMO, there is no bug. There simply is lack of documentation, documenting a behavior some users don't expect, they could easily work-around inside of their Makefile.am, which rarely has caused mal-functions. What you are doing now is _breaking_ what used to work == regression. Ralf
How to tell Automake about dependencies between source files.
Hi, I have to following problem (in an modernized TeX Live build system): A program is built conditionally from distributed and generated sources. Some of the distributed C files include generated headers and therefore can not be compiled before these headers are generated. A related problem: a tool generates a C file plus header from one source, and another C file plus header from another source. Each of these C files includes both headers, therefore the C files can not be compiled before both headers have been created. What is the best way to teach this kind of dependencies to Automake, avoiding unnecessary tasks, not interfering with Automake's automatic dependency tracking, and not having 'make dist' gratuitously build files that are never used. Best regards Peter Breitenlohner p...@mppmu.mpg.de
Re: Serial number formats
Hello Bruno, all, * Bruno Haible wrote on Tue, Mar 17, 2009 at 12:53:19AM CET: Eric Blake wrote: Maybe the solution is to expand automake's list of valid serial lines. True, it won't help until after the next Automake release, but if there are enough files in the wild that use '# file.m4 serial n', it seems like we should make it a valid format rather than forcing all those files to change. For information: autopoint-0.18 will use this code to extract the serial version from the first line: sed_extract_serial='s/^#.* serial \([^ ]*\).*/\1/p 1q' existing_serial=`sed -n -e $sed_extract_serial $1 What exactly is the point of using a different format and extraction code than aclocal does? If this is incompatible on purpose, rather than by accident, then why not come out and state so flatly, and consequently use a format that isn't accidentally mistaken by humans to be compatible? Gettext is using a format slightly incompatible to the aclocal one here, it's confusing for users that it does so, since it is not different enough to be realized as being different. I have so far seen no reason whatsoever why aclocal should change, rather than Gettext. The aclocal format for serial numbers can embody all needed information, as noted by Colin. Thanks for enlightening me. Cheers, Ralf
