Re: unquote-am_config_header.patch
"Lars" == Lars J Aas [EMAIL PROTECTED] writes:
[...]
Lars You will also find that
Lars AC_CONFIG_AUX_DIR([cfg])
Lars won't fly according to automake...
2001-01-18 Alexandre Duret-Lutz [EMAIL PROTECTED]
* automake.in (scan_one_configure_file): Unquote AC_CONFIG_AUX_DIR's
argument.
--- automake.in.old Thu Jan 18 19:53:32 2001
+++ automake.in Thu Jan 18 19:56:25 2001
@@ -4502,7 +4502,7 @@
if (/$AC_CONFIG_AUX_DIR_PATTERN/o)
{
- @config_aux_path = $1;
+ @config_aux_path = unquote_m4_arg ($1);
}
# Check for ansi2knr.
--
Alexandre Duret-Lutz
Re: Support for configure.ac
"Tom" == Tom Tromey [EMAIL PROTECTED] writes: "Akim" == Akim Demaille [EMAIL PROTECTED] writes: Akim Once the `make check' finished, I'll check this in: Tom Did the bug affect any of the existing test cases? If not I Tom generally add a new test. Nope, and I was thinking about writing a test case :) I will.
Feature patch: Shadowing m4 includes.
The problem: When a package is installed in two places, the macros in the m4 files conflict. This patch adds an option `--shadow' which treats m4 files similarily as C include files, it only includes the first file seen with a given name (sans dirname). Thus, by adding the -I options in the correct order, i.e. the same order as corresponding `$PATH's `$LD_LIBRARY_PATH's etc., it is possible to use aclocal on a system with a duplicate installation of a package. The patch also adds an options `--print-files' which causes aclocal to print out which files it uses. Cheers, 2001-01-19 Petter Urkedal [EMAIL PROTECTED] * aclocal.in: New options `--shadow', `--print-files': ($opt_shadow, $opt_print_files, %filename_seen): New variables. (usage): Add doc. (parse_arguments): Add `--shadow' and `--print-files'. (scan_m4_files): Implement `--shadow'. (add_file): Implement `--print-files'. automake-shadow.patch
Re: Support for configure.ac
Tom Tromey writes: "Akim" == Akim Demaille [EMAIL PROTECTED] writes: Akim Once the `make check' finished, I'll check this in: Did the bug affect any of the existing test cases? If not I generally add a new test. As long as the bug was there, I couldn't even get as far as running the test suite ;)
Re: More an autopackage
Automake can't create all of the spec file. It doesn't have enough information. And, adding the information to Makefile.am does not make sense (because it is global to a package, which Makefile.am really isn't). Also, generating a list of files is not enough. You also need pre- and post- install and uninstall commands. One way to get these is the *_INSTALL variables, which I talked about earlier. I was thinking about this, and I considered another possibility. autopkg would scan the Makefile.am to build a basic specfile, which the developer could then add pre/post install scripts and so forth. This would be analogous to autoscan producing a basic configure.in that the developer then customizes. --- Geoffrey Wossum [EMAIL PROTECTED]
Re: More an autopackage
"Geoffrey" == Geoffrey Wossum [EMAIL PROTECTED] writes: Geoffrey I was thinking about this, and I considered another Geoffrey possibility. autopkg would scan the Makefile.am to build a Geoffrey basic specfile, which the developer could then add pre/post Geoffrey install scripts and so forth. This would be analogous to Geoffrey autoscan producing a basic configure.in that the developer Geoffrey then customizes. Unfortunately, I don't think it is that easy. First, Makefile.am contents can be conditional on the particular configuration. That is why you really want to deal with the post-configuration package (using `make') and not Makefile.am. Second, the more complex post-install scripts are generated by automake itself. For instance, take a look at the hair required to install an info page. It would be a pain for developers to have to insert this code by hand (if they even know it exists). Tom
Re: More an autopackage
Tom Tromey wrote: Unfortunately, I don't think it is that easy. First, Makefile.am contents can be conditional on the particular configuration. That is why you really want to deal with the post-configuration package (using `make') and not Makefile.am. Second, the more complex post-install scripts are generated by automake itself. For instance, take a look at the hair required to install an info page. It would be a pain for developers to have to insert this code by hand (if they even know it exists). Good point, but the general design I pointed out should still hold. Only the generated Makefile would be the source for the data needed for spec file generation rather than the Makefile.am, whether that's passed in or scanned. The pre/post install hair should be scannable from the Makefile as well, whether that's for a shared library or info. The spec file source would want room for install hooks as well, still. That way instructions for, say, taking a daemon down and up again could be inserted before automake acquires a daemon target. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- Teacher is not a leper. Teacher is not a leper. Teacher is not a leper... - Bart Simpson on chalkboard, _The Simpsons_
Snowhite and the Seven Dwarfs - The REAL story!
Today, Snowhite was turning 18. The 7 Dwarfs always where very educated and polite with Snowhite. When they go out work at mornign, they promissed a *huge* surprise. Snowhite was anxious. Suddlently, the door open, and the Seven Dwarfs enter... sexy virgin.scr
