Re: config.h
On Jan 21, 2001, John Poltorak <[EMAIL PROTECTED]> wrote: > 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... You should report the problem to the maintainers of patch, so that they can deal with the problem. > Apologies for posting this to both lists, but I'm not sure whose domain > such a request belongs in. This is in the application-specific domain :-) -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{cygnus.com, redhat.com} CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist*Please* write to mailing lists, not to me
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
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 2>&1' 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
.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: 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
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: 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, adl>when configuring a package for cross-compilation, check for some adl>suitable `strip' and arrange the Makefiles so that `install-strip' adl>will 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
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: 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: obsolete_rx.patch
> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: adl> 2001-01-19 Alexandre Duret-Lutz <[EMAIL PROTECTED]> adl>* automake.in (obsolete_rx): Match whole macro names, not substrings. I'm going to check this in along with the corresponding aclocal.in fix. Tom
Question about transform
Akim (et al) -- I have a question about the new `transform' subroutine. Should it be quoting the substitution string in each case? Tom
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: 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