Re: More an autopackage
I think "layers" of config.site would be useful for parts of autopackage. There are other a number of packages out there that attempt to solve this problem in different ways, with varying degrees of success. One set of extremes is the GNU stow project v. the Modules project. Lately I'm playing with ark.sourceforge.net, which seems to do a nice job of melding a lot of the issues well, and taking a larger view approach. H
Re: unquote-am_config_header.patch
"adl" == Alexandre Duret-Lutz [EMAIL PROTECTED] writes: adl AM_CONFIG_HEADER([config.h]) adl May I suggest the change below? (I browsed the source and didn't adl find something similar to unquote_m4_arg, that's quite adl surprising; did I missed something?) This looks good to me. Unfortunately it is long enough to require paperwork before I can check it in. adl + # don't count orphan right brackets adl + $depth = 0 if $depth 0; How important is this? I'm considering rewriting the patch so that unquote_m4_arg simply uses a regexp. Then I think I can check it in immediately. I agree a function like this would be very useful. Sometimes seemingly obvious helper functions go unimplemented for no good reason (historical usually). For instance Akim's recent addition of `transform' -- wish I'd had that a long time ago. Tom
Re: Duplicate entry in THANKS.
"Uwe" == Uwe Hermann [EMAIL PROTECTED] writes: Uwe I was just browsing the THANKS file of the CVS automake and found Uwe a duplicate entry: Thanks, I fixed this. Tom
Re: AC_CONFIG_FILES with : in a subdirectory [test]
"Kevin" == Kevin Ryde [EMAIL PROTECTED] writes: Kevin * tests/colon7.test: Grep for a couple of AC_OUTPUT problems. Thanks, I checked this in. I don't know when I'll fix the bug but it will definitely be before the next release. Tom
Re: PATCH: make install-strip in cross-compilation environments
"adl" == Alexandre Duret-Lutz [EMAIL PROTECTED] writes: adl Can someone explain me the comment before the install-strip adl rule: "We can't just set INSTALL_PROGRAM because that might be a adl relative path". This comment was added with the following adl ChangeLog entry: If there is no vendor install program, autoconf will choose install-sh. The path to install-sh might be a relative path, because $srcdir might be relative. However if we set INSTALL_PROGRAM and invoke $(MAKE), the new value will be passed to subdir Makefiles -- where it will be wrong. adl I'm assuming it is now obsolete, but maybe I'm plain wrong. adl You'll tell me. I'm afraid it is still an issue. Fixing it might be as simple as doing something like: install=`cd $(top_builddir) pwd`/$(install_sh) ... but I just thought that up and I'm not entirely positive. adl 2001-01-20 Alexandre Duret-Lutz [EMAIL PROTECTED] adl`install -s' does not work on cross-compiled programs. Therefore, adlwhen configuring a package for cross-compilation, check for some adlsuitable `strip' and arrange the Makefiles so that `install-strip' adlwill run `install-sh' with `STRIPPROG' set to the detected `strip'. One nit: comments like this should go in the code, not in the ChangeLog. In order to install a patch of this size I'll definitely need paperwork from you. Unfortunately the FSF has changed the procedure recently, and I still don't know the new method. It will be a few days until I dig up the new procedure and get the information to you :-(. (Unless you've already filled it out and I've simply forgotten, which is a definite possibility.) Tom
Checking the CONFIGURE_AC failure
Here is my proposal. Index: tests/ChangeLog from Akim Demaille [EMAIL PROTECTED] * vtexi.test: Also check that stamp-vti properly depends upon configure.in and the Texinfo source file. Index: tests/vtexi.test --- tests/vtexi.test Sat, 13 Jan 2001 18:11:09 +0100 akim (am/11_vtexi.test 1.1 755) +++ tests/vtexi.test Sun, 21 Jan 2001 23:46:18 +0100 akim (am/11_vtexi.test 1.1 755) @@ -1,12 +1,5 @@ #!/bin/sh -# Test for bug reported by Jim Meyering: -# When I ran automake-0.29 on textutils, -# I noticed that doc/Makefile.in had -# textutils.info: textutils.texi -# instead of -# textutils.info: textutils.texi version.texi - . $srcdir/defs || exit 1 cat Makefile.am 'END' @@ -22,6 +15,22 @@ : mdate-sh : texinfo.tex -$AUTOMAKE || exit 1 +set -e + +$AUTOMAKE + +# Test for bug reported by Jim Meyering: +# When I ran automake-0.29 on textutils, +# I noticed that doc/Makefile.in had +# textutils.info: textutils.texi +# instead of +# textutils.info: textutils.texi version.texi grep '^textutils\.info: textutils\.texi .*version\.texi$' Makefile.in + +# Test for bug reported by Lars Hecking: +# When running the first version of configure.ac aware automake, +# @CONFIGURE_AC@ was not properly substitued. + +egrep '^\$\(srcdir\)/stamp-vti:.*textutils\.texi( .*)?$' Makefile.in +egrep '^\$\(srcdir\)/stamp-vti:.*$\(top_srcdir\)/configure\.in( .*)?$' Makefile.in
Re: Checking the CONFIGURE_AC failure
Akim * vtexi.test: Also check that stamp-vti properly depends upon Akim configure.in and the Texinfo source file. This is ok. Akim +set -e I usually use explicit `|| exit 1' after commands. But it probably doesn't matter. Tom
.jar files.
I'm trying to get automake to build a Makefile that will update the project's `.jar' file whenenver any `.java' files get compiled. No success so far. Can someone give me a solution to this?
Re: using pswrap
"trevor" == trevor [EMAIL PROTECTED] writes:
trevor one of the first steps that must take place in order to
trevor compile is to apply a function called "pswrap" to the "*.psw"
trevor file to generate both a *.h and a *.c file; much the same as
trevor using LEX and YACC.
trevor the "Makefile.am" that i came up with for the "code" folder looks like
trevor this:
trevor
trevor SUFFIXES = .psw .h
trevor noinst_PROGRAMS = example
trevor example_SOURCES = example.c wraps.c
trevor example_DEPENDENCIES = wraps.h wraps.c
trevor EXTRA_DIST = wraps.psw
trevor example_LDADD = $(X_LIBS) $(X_PRE_LIBS) -lX11 $(X_EXTRA_LIBS)
trevor INCLUDES = $(X_CFLAGS)
trevor .psw.c:
trevor pswrap -a -o ${@} $
trevor .psw.h:
trevor pswrap -a -h ${@} $ /dev/null
Using `' here isn't portable. Use ` /dev/null 21' instead.
trevor 1) is this okay? is this a decent Makefile.am file to
trevor accomplish that which i am trying to do?
Yes.
trevor 2) when i do the "make" it compiles perfectly fine and
trevor everything is nice. but i noticed that although i've clearly
trevor specified that both "wraps.h" and "wraps.c" are prerequisites
trevor for "example", only "wraps.h" gets created before "example.c"
trevor gets "gcc -c". this isn't a problem since everything works out
trevor well enough since at this stage it's doing a compile only. i'm
trevor just wondering why i get this behaviour.
Probably because of how make decides to construct the dependency tree.
Adding `BUILT_SOURCES = wraps.h wraps.c' might help.
trevor 3) it's a bit of a lie to say that "wraps.c" is a source,
trevor since it doesn't exist until the "pswrap" utility is
trevor executed. but if i don't specify it this way then when the
trevor final link is performed it won't link in "wraps.o" in with
trevor "example.o" to create "example". is there a better way to do
trevor this?
You could try just putting `wraps.psw' into example_SOURCES. This
might work.
Or you could fool around with example_LDADD, but that is probably more
painful than what you're presently doing.
trevor 4) when i do a "make dist", a "wraps.c" file gets included in
trevor the distribution (even if i explicitly delete it before the
trevor "make dist"), i assume this is because of the
trevor "example_SOURCES" line including "wraps.c". i don't want to
trevor include my "wraps.c" since different platforms might create
trevor this file differently. any ideas how i can do this (i guess
trevor this is probably still more of the same with regards to my
trevor previous point (3))?
Remove wraps.c and wraps.h from the distribution in a dist-hook.
This is probably documented; if not please tell me and I'll fix it.
trevor 5) i would like to create a "clean::" target that would $(RM)
trevor the "wraps.[ch]" files, but "make" complains that the
trevor "Makefile" contains both "clean:" and "clean::" targets. how
trevor to i add my own "clean" targets?
This is documented. Use CLEANFILES.
You can't add a "::" rule that conflicts with an automake-generated
rule.
trevor 6) i think it would be nicer to modularize this (much the same
trevor as with LEX and YACC) how would i go about this? should i
trevor create my own *.m4 file with the necessary scripts? i'm not an
trevor autotools expert but i think having a "example_WRAPS =
trevor wraps.psw" line would be nice.
More in the automake style would be to put the .psw files into
_SOURCES. This might work already (in the context of your
Makefile.am); I forget.
Tom
config.h
I'm not really sure where config.h falls into the scheme of building apps using AUTO(MAKE|CONF), but I've found that for PATCH to get built on OS/2, it requires this single addition to config.h:- #define strncasecmp strnicmp How would I go about getting this line included in config.h if... checking host system type... i386-pc-os2_emx Apologies for posting this to both lists, but I'm not sure whose domain such a request belongs in. -- John
