Re: INSTALL_DATA += -p
() Nick Bowler () Tue, 3 Nov 2020 11:21:51 -0500 In general, preserving timestamps while copying files cannot be done reliably and when it is possible, it is difficult to do in a portable fashion. [ideas] Right, preservation is not really required. > The background reason is that i am installing .scm and .go > files (the latter compiled from the former) and the .go > files need to have a "later" timestamp than the .scm files > for Guile to DTRT. "Later" here means "greater than?" Or is "greater than or equal to" acceptable? I need "greater than or equal", i think (from reading libguile/load.c func ‘compiled_is_fresh’). > I suppose a workaround is to use an installation hook to > simply touch(1) the .go files. An install hook would be my recommendation. You should touch both files, as some "touch" implementations truncate timestamps (this means a touched file could potentially get an earlier timestamp than an untouched one). Touching both files only ensures "greater than or equal to" timestamps. If the timestamps must also be different then this is a bit trickier (call touch in a loop until the timestamp changes). Thanks. I didn't think/know about the (potential) truncation. -- Thien-Thi Nguyen --- (defun responsep (query) ; (2020) Software Libero (pcase (context query) ; = Dissenso Etico (`(technical ,ml) (correctp ml)) ...)) 748E A0E8 1CB8 A748 9BFA --- 6CE4 6703 2224 4C80 7502 signature.asc Description: PGP signature
INSTALL_DATA += -p
I'd like to make sure that timestamps are preserved on "make install". I found the variable ‘INSTALL_DATA’ but cannot do the above (subject line) addition to Makefile.am, because Automake interprets INSTALL as a primary and bails out since that is not defined as such. The background reason is that i am installing .scm and .go files (the latter compiled from the former) and the .go files need to have a "later" timestamp than the .scm files for Guile to DTRT. I suppose a workaround is to use an installation hook to simply touch(1) the .go files. Is there a better way to do this? -- Thien-Thi Nguyen --- (defun responsep (query) ; (2020) Software Libero (pcase (context query) ; = Dissenso Etico (`(technical ,ml) (correctp ml)) ...)) 748E A0E8 1CB8 A748 9BFA --- 6CE4 6703 2224 4C80 7502 signature.asc Description: PGP signature
Re: Part 2: Add Cleanfiles for User Defined Special Sources [Re: How to add new Makefile-Rules through Configure?]
() Marc Wäckerlin () Tue, 10 Mar 2015 10:47:37 +0100 Any comments on what is a proper solution? I think this kind of scan + conditionalized-inclusion mucking is best done in autogen.sh by way of creating m4 fragments for configure.ac and makefile fragments for the Makefile.am file(s). To be precise, all this should happen before calling autoreconf. If you can maintain this phase separation, life is easier. -- Thien-Thi Nguyen GPG key: 4C807502 (if you're human and you know it) read my lisp: (responsep (questions 'technical) (not (via 'mailing-list))) => nil signature.asc Description: PGP signature
Re: "make check" clean up
() Luke Mewburn () Wed, 26 Nov 2014 11:23:26 +1100 I work around this by having specific test groups to start the daemons with AT_KEYWORDS([start]), and separate test groups I run at the end with AT_KEYWORDS([stop]). The tests for stopping the daemons don't fail if the daemon isn't running; the exit 77 if the daemon isn't running to skip that stop group. [details] Thanks for describing this Autotest setup. I will experiment. -- Thien-Thi Nguyen GPG key: 4C807502 (if you're human and you know it) read my lisp: (responsep (questions 'technical) (not (via 'mailing-list))) => nil signature.asc Description: PGP signature
"make check" clean up
Is there any way to specify an unconditionally executed clean-up action for "make check"? In Guile-PG, "make check" arranges to kick a daemon prior to running the tests in the test wrapper script, and to kill it afterwards via a ‘check-local’ Makefile.am target. This works fine when all the tests pass, but leaves the daemon up should any of the tests fail. For now, i've documented this in the README: http://git.savannah.gnu.org/cgit/guile-pg.git/tree/README?h=p#n109 but we all know how such hints are easily overlooked, and i'd prefer a more robust solution that can DTRT noninteractively. -- Thien-Thi Nguyen GPG key: 4C807502 (if you're human and you know it) read my lisp: (responsep (questions 'technical) (not (via 'mailing-list))) => nil signature.asc Description: PGP signature
Re: stripping directory component from installation file pathname
() Marco Maggi () Mon, 24 Feb 2014 12:49:15 +0100 I just want to strip the string prefix "lib/" from the installation pathnames. Maybe you can use a var that includes the trailing slash: intreelib = lib/ ..._DATA = \ $(intreelib)stuff/foo.fasl and then replace the usual "make install" flow via: install-data-local: $(MAKE) install-data-am intreelib= This would mimic the -data side of "make install" (i think). -- Thien-Thi Nguyen GPG key: 4C807502 (if you're human and you know it) read my lisp: (responsep (questions 'technical) (not (via 'mailing-list))) => nil pgpgl5FbPaxNo.pgp Description: PGP signature
Re: Want "make check" to test shared, static lib
() Torbjorn Granlund () Wed, 13 Nov 2013 18:45:30 +0100 We in the GMP project would like to have "make check" run through our testsuite for both the static and shared libs (when both are built). This is only necessary if there are significant differences (in user-visible behavior) between a static and shared-lib build. That sounds weird to me. What am i missing? -- Thien-Thi Nguyen GPG key: 4C807502 (if you're human and you know it) read my lisp: (responsep (questions 'technical) (not (via 'mailing-list))) => nil pgp0uqKNmug8h.pgp Description: PGP signature
Re: Can automake move aclocal.m4 into subdirectory?
() Bob Rossi () Mon, 22 Apr 2013 20:52:27 -0400 On Fri, Apr 12, 2013 at 10:06:02PM -0400, Bob Rossi wrote: > Is it possible to tell automake to move the generated file > aclocal.m4 into a build subdirectory? In (info "(autoconf) autoreconf Invocation") there is: If you want `autoreconf' to pass flags that are not listed here on to `aclocal', set `ACLOCAL_AMFLAGS' in your `Makefile.am'. Due to a limitation in the Autoconf implementation these flags currently must be set on a single line in `Makefile.am', without any backslash-newlines. so if you use autoreconf (which is Recommended) in the bootstrap flow, you can try adding ACLOCAL_AMFLAGS = --output build/m4/aclocal.m4 to the top-level Makefile.am. I suppose: AC_CONFIG_MACRO_DIR(build/m4) will then be sufficient for the tools to DTRT. I haven't tried this approach yet, having just learned about it, prompted by your query (so thanks for asking!), however. Does it work? -- Thien-Thi Nguyen GPG key: 4C807502 pgp2gxOjWJRrL.pgp Description: PGP signature
Re: [IMPORTANT] Savannah issues
() Stefano Lattarini () Sat, 23 Feb 2013 19:06:14 +0100 I don't have time to look into this presently, so I'd appreciate if anyone could look into the issue (finding a way not have savannah to reject non-fast-forward pushes would be enough). I believe the project maintainer must write to the sysadmins requesting a specific change. GNU RCS is in a similar state (IIUC), the resolution of which is (perhaps) the exchange of ‘master’ and a non-‘master’ names (HEAD pointers). I say "perhaps" because i'm not really sure. More perplexed mumblings at: <http://www.gnuvola.org/u/2013/01/24h09.html>. The point is: For timely resolution, you need to take direct action. Let RCS's (ever-growing) lacuna serve as a warning! -- Thien-Thi Nguyen . GPG key: 4C807502 . NB: ttn at glug dot org is not me . . (and has not been since 2007 or so) . .ACCEPT NO SUBSTITUTES . ... please send technical questions to mailing lists ... pgpOesbqSL3hT.pgp Description: PGP signature
Re: Removal of INCLUDES in favour of AM_CPPFLAGS
() Stefano Lattarini () Fri, 01 Feb 2013 19:59:58 +0100 A first step would certainly be making it a separate project on Savannah, rather than just a glorified branch in the Automake Git repository (plus a dedicated mailing list). Anyone has experience or suggestions on how to better proceed in this direction? No no, that will only let things drift apart more quickly. While everything is still in one head (yours), it should be in one repo, IMHO. Perhaps you should post a "help wanted" notice, select a worthy hacker for Automake (presuming you want to focus on Automake-NG) from the throng of candidates (one hopes), and then, after a suitable ramp-up period, let the new maintainer decide the fate of the code. [cc -> to, trimmed] -- Thien-Thi Nguyen . GPG key: 4C807502 . NB: ttn at glug dot org is not me . . (and has not been since 2007 or so) . .ACCEPT NO SUBSTITUTES . ... please send technical questions to mailing lists ... pgpZlQai2GSDG.pgp Description: PGP signature
Re: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
() Stefano Lattarini
() Mon, 28 Jan 2013 20:48:59 +0100
So I propose the following change in the Automake versioning scheme:
[...]
Sounds good. Going further, you could maybe define notation (described
in HACKING) for categories of changes (backward-{in}compatible, etc) and
methodically use them in the ChangeLog entries. This would be both
informative to the user, and helpful to prevent mistakes (by casual
contributors :-D).
I also propose the following change to the branching scheme currently
implemented in the Automake Git repository:
[...]
These details should also be explained in HACKING.
to publicize the new versioning scheme
- ??? (suggestions welcome)
Maybe cut a release that changes only the version number? Personally i
would find that to be not particularly useful, but others might welcome
the explicitness.
--
Thien-Thi Nguyen . GPG key: 4C807502
. NB: ttn at glug dot org is not me .
. (and has not been since 2007 or so) .
.ACCEPT NO SUBSTITUTES .
... please send technical questions to mailing lists ...
pgpT68ZhxJRYE.pgp
Description: PGP signature
Re: Makefile to Makefile.am
() Ralf Wildenhues
() Sun, 15 Aug 2010 23:32:44 +0200
Yes, with a general example, please.
I am unsure what "general example" means, precisely, so
the patch below simply uses the one in The GNU Make Manual.
Is that ok?
_
>From 7b70f8b27057c5b9a0f621dcfd5064c5d90947dd Mon Sep 17 00:00:00 2001
From: Thien-Thi Nguyen
Date: Mon, 16 Aug 2010 02:14:56 +0200
Subject: [PATCH] Document a common conversion for GNU make pattern rules.
* doc/automake.texi (Multiple Outputs): Expand on GNU make
pattern rules; explain how to convert a common case to use
old-fashioned suffix rules; add simple example, xref.
---
ChangeLog |7 +++
doc/automake.texi | 30 +-
2 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 9ba4851..ca59933 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2010-08-16 Thien-Thi Nguyen(tiny change)
+
+ Document a common conversion for GNU make pattern rules.
+ * doc/automake.texi (Multiple Outputs): Expand on GNU make
+ pattern rules; explain how to convert a common case to use
+ old-fashioned suffix rules; add simple example, xref.
+
2010-08-12 Peter Rosin
Enable the use of "link -lib" as the wrapped archiver.
diff --git a/doc/automake.texi b/doc/automake.texi
index bbb74d3..f95f5cd 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -11525,11 +11525,31 @@ @node Multiple Outputs
@c $$
For completeness it should be noted that GNU @command{make} is able to
-express rules with multiple output files using pattern rules
-(@pxref{Pattern Examples, , Pattern Rule Examples, make, The GNU Make
-Manual}). We do not discuss pattern rules here because they are not
-portable, but they can be convenient in packages that assume GNU
-...@command{make}.
+express rules with multiple output files using pattern rules.
+Although pattern rules are not portable, they can be
+convenient in packages that assume GNU @command{make}.
+...@xref{pattern Examples, , Pattern Rule Examples, make, The GNU Make
+Manual}.
+
+In the common case where the @samp{%} in the pattern rule is used to
+match the stem of a filename, and the prerequisite and target differ
+only in the filename extension, you can use the old fashioned suffix
+rule instead. For example:
+
+...@example
+# pattern rule, not portable
+%.o : %.c
+$(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@@ $<
+
+# old fashioned suffix rule, portable
+.c.o:
+$(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@@ $<
+...@end example
+
+Take care, when converting from pattern rule syntax to suffix rule
+syntax, to place the prerequisite extension @file{.c} before that
+of the target extension @file{.o}.
+...@xref{suffix Rules, , Old-Fashioned Suffix Rule, make, The GNU Make Manual}.
@node Hard-Coded Install Paths
--
1.6.3.2
Re: Makefile to Makefile.am
() "samson.pierre" () Sun, 15 Aug 2010 03:09:50 +0200 (CEST) > > %.bmp: %.xcf > > $(GIMP) -i -b '(xcf-bmp "$<" "$@")' -b '(gimp-quit 0)' Is there an equivalent or anything else which can help me to write this rule avoiding this warning message? I think here you can use something like: .xcf.bmp: $(GIMP) -i -b '(xcf-bmp "$<" "$@")' -b '(gimp-quit 0)' Note the order is PREREQ-EXT before TARGET-EXT, which is opposite of the pattern rule order. Probably Automake manual (and its readers) could benefit from changing the mysterious: We do not discuss pattern rules here because they are not portable, but they can be convenient in packages that assume GNU `make'. to something like: Although pattern rules are not portable, they can be convenient in packages that assume GNU `make'. In the common case where the pattern rule is used to match the stem of a filename, you can use the old fashioned suffix rule (pxref here) instead. For example: # pattern rule, not portable %.bmp : %.xcf $(GIMP) -i -b '(xcf-bmp "$<" "$@")' -b '(gimp-quit 0)' # old fashioned suffix rule, portable .xcf.bmp: $(GIMP) -i -b '(xcf-bmp "$<" "$@")' -b '(gimp-quit 0)' Hey, maybe Automake hackers can riff off this thread in time for the next release... (or, "Would you like me to submit a patch?").
playing w/ GCC warnings
What do people do to make experimentation w/ GCC warnings easy? In Guile-PG's configure.in, there is: |## If we're using GCC, ask for aggressive warnings. |if test x"$GCC" = xyes ; then | AGGRESSIVE_WARNINGS="-std=gnu99 -pedantic" | for x in all extra float-equal declaration-after-statement \ | undef shadow pointer-arith cast-qual cast-align aggregate-return \ | old-style-definition no-missing-field-initializers \ | nested-externs inline volatile-register-var disabled-optimization |do AGGRESSIVE_WARNINGS="$AGGRESSIVE_WARNINGS -W$x" | done |fi |AC_SUBST([AGGRESSIVE_WARNINGS]) and in the src/Makefile.am: | AM_CFLAGS = $(AGGRESSIVE_WARNINGS) $(MORE_AGGRESSIVE_WARNINGS) I do this in order to not touch CFLAGS. I wonder if this is contra-indicated somehow, and if not, if the result can be achieved in a better (more idiomatic, more "standard") way. thi
Re: installing only shared lib
() Ralf Wildenhues <[EMAIL PROTECTED]> () Tue, 12 Feb 2008 13:36:29 +0100 Please, do not propagate ugly solutions, unless you know that a clean one does not exist. It's hard to know if a clean one does not exist; i don't maintain these tools and don't generally dig into them more deeply than their documentation. Perhaps propagating ugly solutions will motivate the clean one (that may or may not exist -- you tell me) to show itself. thi
Re: installing only shared lib
() Vincent Torri <[EMAIL PROTECTED]>
() Tue, 12 Feb 2008 08:17:12 +0100 (CET)
a library that I use installs shared libs that will be
loaded with dlopen. That is, the static lib, the .la
files (and the import lib *.dll.a on windows) are not
necessary.
Is there a command to add in a Makefile.am to avoid the
installation of those file, so that only the sahred lib
is installed ?
I'm interested in the answer to this question, as well. In
the meantime, i use the hacky workaround script here attached:
#!/bin/sh
# sofix --- smooth out things after $(LIBTOOL) --mode=install
#
# Copyright (C) 2007 Thien-Thi Nguyen
#
# This file is part of ttn-do, released under the terms of the
# GNU General Public License as published by the Free Software
# Foundation; either version 3, or (at your option) any later
# version. There is NO WARRANTY. See file COPYING for details.
##
# Usage: sofix FLAGS DIR FOO.la...
#
# Change directory to DIR and do various things based on FOO.la
# vars and FLAGS, a comma-separated list of symbols:
#
# no-symlinks -- from the files in library_names=LIST, delete
# those that are symlinks, and update FOO.la
# vars `dlname' and `library_names' as well
#
# no-la -- delete FOO.la
#
# ln-s-lib-- symlink (or copy if no-la) FOO.la to libFOO.la
# [default: remove any such symlinks found]
#
# To specify no flags, use "none". Note, however, that "none"
# does not prevent any libFOO.la files from being deleted anyway.
#
# Lastly, chmod -x the remaining regular (non-symlink) files.
##
version="2.0"
v () { echo sofix $version ; echo ; }
usage () { sed '/^##/,/^##/!d;/^##/d;s/^# //g;s/^#$//g' $0 ; }
[ x"$1" = x--help ] && { v ; usage ; exit 0 ; }
[ x"$1" = x--version ] && { v ; exit 0 ; }
[ x"$2" = x ] && { usage ; exit 1 ; }
flags=,"$1", ; shift
cd $1 ; shift
for la ; do
eval `sed '/^dlname=/!d' $la`
eval `sed '/^library_names=/!d' $la`
case $flags in *,no-symlinks,*)
for name in $library_names ; do
if [ -h "$name" ] ; then
rm -f "$name"
elif [ "$dlname" != "$name" ] ; then
sed -e 's/^\(dlname=\).*/\1'"'$name'"'/' \
-e 's/^\(library_names=\).*/\1'"'$name'"'/' \
$la > ${la}T
mv ${la}T $la
dlname="$name"
fi
done ;;
esac
rm -f lib$la
case $flags in *,ln-s-lib,*)
rep="ln -s"
case $flags in *,no-la,*) rep=cp ;; esac
$rep $la lib$la ;;
esac
chmod -x $la $dlname
case $flags in *,no-la,*) rm -f $la ;; esac
done
# sofix ends here
(part of ttn-do[0] and now .common.git[1]) to delete those
files post-install.
thi
_
[0] http://www.gnuvola.org/software/ttn-do/
[1] http://www.gnuvola.org/wip/
Re: AC_PROG_CC sets CFLAGS, what about AM_CFLAGS?
() Benoit SIGOURE <[EMAIL PROTECTED]> () Mon, 27 Aug 2007 21:12:28 +0200 OK look, here is how it goes AFAIK: - You want to set project-wide flags, use AM_CFLAGS - Your user wants to set project-wide flags, it does: ./configure CFLAGS=... - If your user didn't set project-wide flags, AM_PROG_CC may put some default flags in CFLAGS (that can be safely overridden by the user) What's wrong with this? i don't think anything is "wrong" with how it is SUPPOSED to work (which i understand, but which you do not seem to understand that i understand). don't worry about it. thi
AC_PROG_CC sets CFLAGS, what about AM_CFLAGS?
() Benoit SIGOURE <[EMAIL PROTECTED]> () Mon, 27 Aug 2007 09:48:16 +0200 AM_CFLAGS is reserved for developers. It's not a problem if the user overrides the default value of CFLAGS since CFLAGS is reserved for the user. i understand, and am actually trying achieve, this. my point is that it is the auto* tools themselves that are not helping, or at least i don't know how to request their help to arrange for a situation where "AM_CFLAGS is reserved for developers". what i see is that configure sets CFLAGS and *not* AM_CFLAGS, in apparently normal usage. it seems a contradiction between what is espoused in the docs and what actually happens. however, i see libtool is not directly culpable, so i cc automake folks, instead, and change the subject line. thi
Re: --print-libdir request
() Ralf Wildenhues <[EMAIL PROTECTED]> () Tue, 17 Apr 2007 20:58:11 +0200 You mean, other than `automake --add-missing' (or, short: -a)? not really. Or is it that you'd need something like automake --add-missing --install-even-if-i-do-not-use-automake yes. (for some projects i don't use automake, but i want to symlink some of the (relatively better-maintained) files from its library.) thi
--print-libdir request
some of my autogen.sh (bootstrap script) files use the construct:
amprefix=`automake --help | sed '/^Usage:/!d;s/Usage: //;s,/bin/automake.*,,'`
amlibdir=`ls -d ${amprefix}/share/automake-* | tail -1`
for f in install-sh INSTALL COPYING ; do
ln -sf ${amlibdir}/$f
done
this is not reliable (ls | tail assumes too much), so i was wondering if
automake might support some option to print its libdir to stdout, so that i
could do:
amlibdir=`automake --print-libdir`
for f in install-sh INSTALL COPYING ; do
ln -sf ${amlibdir}/$f
done
or perhaps there is already something available to achieve the same goals,
with automake 1.9?
thi
PATCH: doc/automake.texi
ChangeLog entry:
* doc/automake.texi (Dependency Tracking Evolution): Fix typo.
--- automake.texi 17 Apr 2006 12:14:07 - 1.134
+++ automake.texi 26 Apr 2006 03:03:41 -
@@ -10420,7 +10420,7 @@
@item @command{makedepend}
This was a commonly-used method in the past. The idea is to run a
special program over the source and have it generate dependency
-information. Traditional implementations of @command{makedepend} ere
+information. Traditional implementations of @command{makedepend} are
not completely precise; ordinarily they were conservative and
discovered too many dependencies.
@item The tool
Re: how to run a test file with command line options...
Ed Hartnett <[EMAIL PROTECTED]> writes: > Howdy all! > > If I have some tests, and want to run them with command line options, > how do I do it? > > For example, I have to have a shell script to run tst_parallel below, > because it needs to be called with the poe command, and some env vars > set. In other cases, I need to call test program with some command > line options. > > check_PROGRAMS = tst_parallel > TESTS = run_par_test.sh > > Where run_par_test.sh is: > > MP_TASKS_PER_NODE=4 MP_PROCS=4 poe ./tst_parallel > > This works, but is there a way to do this in the Makefile.am, and not > use a shell script? i remember trying to push the limits of automake testing facilities awhile back, w/o much joy, but perhaps things are better now. still, since you already have a shell script you might as well (ab)use it to get the desired flexibility. indirection is one of the classic (and effective) solutions to Hard Problems everywhere; giving it up seems to be a step backwards. you could, for example, set the TESTS_ENVIRONMENT makefile variable (or parts of it) and have the shell script dispatch based on the values, or filter/pass them to the program as input/arguments. thi
Re: How to get AC_DEFINE to generate a macro, e.g., #define incr(x) ((x)+1) ?
Fred Proctor <[EMAIL PROTECTED]> writes: > How can one get AC_DEFINE to define a variable with an argument > list? I want to do something like this: > > AC_DEFINE(incr(x),((x)+1),"increment") i think either you misunderstand AC_DEFINE or i misunderstand you. where in the documentation is the possibility of such a construct suggested? thi
Re: executable scripts produced by AC_OUTPUT?
Irek Szczesniak <[EMAIL PROTECTED]> writes: > Is there a way of achieving my goal? i believe this can be handled completely by autoconf, w/o involving automake. try placing in configure.ac: AC_CONFIG_FILES([fsclient.sh],[chmod +x fsclient.sh]) AC_OUTPUT tested w/ GNU Autoconf 2.59. thi
Re: [ot]wiki for auto* tools?
"Jay West" <[EMAIL PROTECTED]> writes: I'll host it in exchange for someone taking 60 seconds to answer my previous post ;) probably if you host such a wiki, your questions (or related ones) will receive wider review and potentially useful answers will show up sooner. thi
Re: autoconf 1.x for vms maintainership request
Roger Leigh <[EMAIL PROTECTED]> writes: Maintenance should really include upgrading to the current version of autoconf. that's probably something a maintainer decides, hopefully w/ some input from the users. Is there any VMS support in the older version that is missing in the current version? yes. Are there any other factors that prevent upgrading? Either way, upgrading to the current version and including support for any required VMS support is needed. who is needing it? do you need it? it seems to me from your questions you have not looked closely at autoconf 1.11 for vms, or how it is used to support emacs 19.28 and (not yet released 21.x) for vms. (lucky you! :-) thi
Re: autoconf 1.x for vms maintainership request
From: Bob Friesenhahn <[EMAIL PROTECTED]> Date: Tue, 27 Apr 2004 09:31:43 -0500 (CDT) Autoconf 1.12 is an anchient legacy version dating from eight years ago. The current Autoconf is 2.59. If no one responded, it was probably because your request was similar to proposing a design change to the Model T Ford. it's not so much a design change as maintenance for the benefit of those still using that code w/ more recent VMS environments. for these users, "current" is what is useful, no matter how ancient or legacy it may be considered by others. (believe me, VMS users have heard those particular terms dismissively applied since the very beginning... ;-) thi
autoconf 1.x for vms maintainership request
i posted the following to the autoconf list: http://mail.gnu.org/archive/html/autoconf/2004-04/msg00131.html but perusing the archive shows that list is mostly full of (other) junk, hence this post, in case autoconf maintainers have decided to avoid that list. thi
Re: Building the .info files in build directory.
Kelley Cook <[EMAIL PROTECTED]> writes: Sorry if this is a RTFM, but I can't find it. The release notes for automake 1.8, mention that it changes the defaults to go back to building the .info files in the source directory since that is the GNU coding standards. What do I have to put in my Makefile.am to put them back to being built in build directory like 1.7.x did? FWIW, having a read only source directory is our goal. i voiced this concern a few months back but have found neither the magic incantation in newer releases nor the time to explore the source enough to submit a patch. that is to say, inclination alone is worthless. :-( next, i offered a local programmer 150 euro to do this job but he was busy w/ other things. now, i have decided to save my money and not move away from 1.7 until this feature comes back (whether by my doing or by that of another). that's my story -- maybe you will have better luck. thi
Re: automake -vs- huge projects
"Paul D. Smith" <[EMAIL PROTECTED]> writes: If you're willing to require GNU make then I'm quite confidant you could write automake as nothing more than a suite of GNU make macros and functions. I doubt there would be any need for code changes to GNU make at all. i think it would be cool if automake supported GNU make specifically, creating GNUmakefile.in from GNUmakefile.am. a GNUmakefile.am would imply some automake option "gnu-make-only", while automake option "gnu-make" would create both Makefile.in and GNUmakefile.in. those who use option "gnu-make" would need to include GNUmakefile in configure.ac of course. then, GNU make can DTRT since it prefers GNUmakefile over Makefile, and other make programs can still function (unless option "gnu-make-only" is used by the package maintainer in which case that should be mentioned in README or somesuch). thi
Re: Help Requests
i see from the previous post that you use a "manual VPATH" methodology. there are two approaches you can try: 1/ undo the unorthodoxy (move auto* files to top-level dir) 2/ prefix relative paths (such as "../../") w/ $(srcdir) probably 1/ is the best for minimizing gray hairs long term, although it implies high (but one-time) rework cost. 2/ is best for diagnosing the problem further, as an eventual stepping-stone to 1/. wrt turn-around-time for responses, you can probably expect to find a huge variance even among the same people. e.g., sometimes i don't respond to mail for months or years... thi
Re: Should -i mkdir?
Akim Demaille <[EMAIL PROTECTED]> writes: So, should automake -i make sure the directory exists and create it if needed? Or that would be considered unsafe (a typo in the name, et voil=E0, a nasty dir pollutes your codeshore). perhaps only if --force is also specified, else signal error. thi
Re: how to change the behaviour of "make check"?
Date: Wed, 17 Sep 2003 14:07:17 -0600 (MDT) From: Ireneusz SZCZESNIAK <[EMAIL PROTECTED]> Yeah! But still I want the output of "make check" to be clean. When a test fails, then I expect to see: "FAIL: test.sh". in this case the only thing i can suggest is to post-process the Makefile to change the "check-TESTS" target near the end to not check for failures. you might offend purists, but anyway, this can be done like so: ./configure cp Makefile TMP grep -v "^[]*test ...failed. -eq 0" TMP > Makefile rm TMP make note that there is both an embedded tab and a space between the square braces. the cp-grep-rm sequence can actually be done by the configure script itself w/ some AC_CONFIG_COMMANDS construct. then the only thing you would have to worry about is future automake breaking the regexp (it seems unlikely but you never know when GNU hackers are involved ;-). thi
Re: how to change the behaviour of "make check"?
Ireneusz SZCZESNIAK <[EMAIL PROTECTED]> writes: But I only want "make" to ignore errors from running tests, not all errors. My test scripts are automatically generated by "make" and then run. If "make" fails to generate such a script, then I want "make" to report the error and stop. there is a documented Makefile.am var TESTS_ENVIRONMENT which you can use to not only set various env var variables, but specify a completely different interpreter aside from the bourne shell, to run the tests. for example, if your tests write some debugging info to a separate LOGFILE, then you might use this script: #!/bin/sh # fake-sh --- customized replacement for /bin/sh /bin/sh "$@"# first, do it status=$? # save the return value if grep -q REALLYFAIL LOGFILE ; then exit $status else exit 0 # fake success fi # fake-sh ends here by specifying TESTS_ENVIRONMENT = FOO=1 BAR=2 $(top_srcdir_absolute)/fake-sh (the nicely formatted messages will be wrong (since you are faking success some of the time), but presumably you are smarter than to believe w/o scrutiny anything you read on computer screen, like this message ;-) thi
Re: zonking .la and .a files
argh! it figures, the answer is actually in autoconf: AC_DISABLE_STATIC AM_PROG_LIBTOOL sorry for the noise. thi
zonking .la and .a files
greetings libtool and automake folks, is there any way to tell libtool/automake NOT to install .la and .a files? i would like to install only the shared object libraries as "plugin modules" (the main program knows of the plugin modules location and can dlopen them directly w/o search; there is no requirement for linking against the module in the future). here's a kludge i came up w/ that works but seems inelegant: my_LTLIBRARIES = libfoo.la libfoo_la_SOURCES = foo.c libfoo_la_LDFLAGS = -version-info 0:0 -export-dynamic -module install-exec-hook: rm -f $(DESTDIR)$(mydir)/libfoo.la rm -f $(DESTDIR)$(mydir)/libfoo.a thanks for any insight into this problem. fwiw, i'm using libtool 1.4.3 and automake 1.7.6. thi
Re: Is a ChangeLog file realistic if /lots/ of developers adding/lots/ of changes?
From: [EMAIL PROTECTED] Date: Wed, 25 Jun 2003 13:57:26 -0700 This overhead will take work and commitment from people. How much improvement can this deliver?? 10%? 50%? 500%? the way to look at it is that you WANT work and commitment from people, but you want the right kind of work and commitment. the improvement cannot be measured simply w/ a number, so if you are looking for that kind of change, this advice is not for you. Is this advice meant only for large (>10? >100?) development groups??? it's meant for any size group that wants to work smarter and that has the desire and discipline to try that method. of course, you have to tweak the method as you scale up. for a very large group, feel free hire a management consultant (who will give you pretty much the same advice but w/ glossy brochures ;-). The reason I am asking is that I usually work on projects with <10 developers. Things usually get done somehow regardless. well, the art of manglement is to finesse the "somehow" into "our how" where "our" is customized to the particular group's dynamics, tight in the right places, and slackful in the right places. that's a lot of weasel words, you are sure to notice. the activity i suggested falls into the general class of "reflective activity" which is, at its core, a force that works to oppose weasling. that's why all art is ironic, btw. (I got a bad deal when I went crazy about OOP and decided to do everything object oriented only to discover that small projects don't necessarily benefit from OOP. Sometimes OOP can even *slow down* a little project. I hope this ChangeLog business is not another "OOP") it all depends on the people who have to carry it out. good luck! thi
Re: Is a ChangeLog file realistic if /lots/ of developers adding/lots/ of changes?
From: Ronald Landheer-Cieslak <[EMAIL PROTECTED]> Date: Fri, 20 Jun 2003 11:52:25 +0200 (CEST) That is actually a very good idea! that's why they pay me the big bux (oh wait... ;-) thi
Re: Is a ChangeLog file realistic if /lots/ of developers adding/lots/ of changes?
[EMAIL PROTECTED]: If you have any advice or ways to streamline the process I would very much like to hear it. spend one hour a week as a group reading change logs (and only change logs -- no code!) for the week preceding. discuss applicability of changes, especially whether or not the change introduces new problems. note change/changeback pairs. characterize and categorize changes to determine if a larger-scope redesign is indicated (or rather, soon to be indicated :-). over time, this will streamline things because your group will be able to recognize useless (or less than optimal) changes that should never have been made in the first place, and thus reduce that kind of noise. you might also develop ability to pre-emptively figure out more direct and more robust changes to make. basically, to understand the code is one thing, to understand how you change your code is the next best thing, and to understand how you understand how you change your code is the best thing. change logs can help you do this. thi
Re: software build
Enrico Weigelt <[EMAIL PROTECTED]> writes: I'd like to invite you to this project. how do you handle cycles in the tree? how do you handle multiple roots? how do you handle transient relations? thi
Re: proposal to fork the build-tools projects
From: Dan Kegel <[EMAIL PROTECTED]> Date: Mon, 21 Oct 2002 10:51:51 -0700 You think the world is ready for Guile? guile is not ready for the world. current install practice spews .la and .so files all over $libdir and uses an internal "bugfixed" copy of libltdl (if my reading of the cvs commit logs is accurate). this is in the grand solipsistic tradition of guile development, which bletcherous nature (at present) is addressed by the OP's analysis. probably other projects suffer from similar manglement, which is why the analysis is relevant. that discussion does not continue is not surprising given that most programmers w/ available cycles to burn have difficulty smashing their ego in the name of Quality. although my response was another way of pointing this out, i think that regardless of human predilections the rise of software accountability, as implemented by OP's change proposal or otherwise, is inevitable. source code is just artifact, bits on a hard drive, a sentence w/o context. if you trust the speaker, fine. if you don't, where does that leave you? i'll tell you: in the same boat as those who trust their pensions to another whose methods are not known, in the same boat as those who trust their rights to another whose methods are not known, and so on. the suffering of people through ignorance is historic. knowing the method of software production is one way (perhaps the only way) of building trust in it. towards this, the auto* and like-minded tools should strive, and in doing so, help the people using those tools find courage in improving themselves and society at large. Can I have some of what you're smoking, please? :-) i ran out a while back, sorry. thi
Re: proposal to fork the build-tools projects
sounds about right -- finding the appropriate mux point to pinch is indeed the
first step towards sanity. if you get funding, give me a buzz. otherwise, i
will continue to work w/ (old) librx and approach the problem from the guile
perspective. (e.g., below is lex.test w/ a simple shell-lexer spec. probably
guile will be able to do a busybox-like sumo move on the auto* tools by end of
1.4.x.)
the broader social hack is going to be difficult, if anything. people don't
like to reflect because the image they see (initially) is one of incompetence
and foolishness. it takes fortitude to synthesize that stark realization into
actions that support their ideals (and self-image). much easier to deny the
proper place of reflection entirely, along w/ its past implication and future
consequence. ah, children w/ magic wands...
given this, probably the best you can do is to write analysis tools that help
people migrate from the pre- to the fully-muxed state. (i see "autoupdate" is
a step in this direction.) M-x refactor-build-flow, you know.
thi
__
#!/bin/sh
exec ${GUILE-guile} -s $0 "$@" # -*- scheme -*-
!#
;;; Commentary:
;; Usage: $(INST_TESTS_ENVIRONMENT) $(srcdir)/lex.test
;;
;; Basically, we construct a lexer on ourselves; do not modify
;; anything above the commentary line w/o also modifying the
;; associated values in `expected' below!
;;; Code:
(use-modules (lang lex))
;; simple references
lexeme-reader
lexer-regexp-and-handler
make-lexer
eof-token?
;; from comment
(define r (regcomp "if[[:cut 1:]]\\|else[[:cut 2:]]"))
(or (equal? (regexec r "if" '(#\c 0)) '(1 "if"))
(error "'(#\c 0) on \"if\" failed"))
(or (equal? (regexec r "else" '(#\c 0)) '(2 "else"))
(error "'(#\c 0) on \"else\" failed"))
;; from comment using make-lexer
(define ifelse-lexer (make-lexer '(("if" if) ("else" else
;; self lexing -- incomplete spec for testing purposes only
(define (token->number token . port) (list 'number (string->number token)))
(define (token->id token . port) (list 'identifier (string->symbol token)))
(define shell-script-lexer-spec
`(("[0-9]\\+" ,token->number)
("/\\([a-zA-Z0-9,=_-]\\+/*\\)*" filename)
("\"\\$@\"" ,(lambda ignored '(dollar-at)))
("\\$" ,(lambda ignored '(dollar)))
("{",(lambda ignored '(left-curly)))
("}",(lambda ignored '(right-curly)))
("exec" ,(lambda ignored '(exec)))
("#!" ,(lambda ignored '(hash-bang)))
("!#" ,(lambda ignored '(bang-hash)))
("[A-Za-z0-9_][A-Za-z0-9_]*" identifier)
("-",(lambda ignored '(dash)))
("\n" ,(lambda ignored '(newline)))
("#[^!][^\n]*" comment)
("." ignored)))
(define shell-script-lexer (make-lexer shell-script-lexer-spec))
(or (procedure? shell-script-lexer)
(error (format #f "not a procedure: ~S" shell-script-lexer)))
(use-modules (ice-9 lineio))
(define p (make-line-buffering-input-port
(open-input-file (car (command-line)
(or (lineio-port? p)
(error (format #f "not a lineio port: ~S" p)))
(define expected
'((hash-bang)
(filename "/bin/sh")
(newline)
(exec)
(dollar)
(left-curly)
(identifier "GUILE")
(dash)
(identifier "guile")
(right-curly)
(dash)
(identifier "s")
(dollar)
(number 0)
(dollar-at)
(comment "# -*- scheme -*-")
(newline)
(bang-hash)
(newline)))
(define expected-length (length expected))
(define (next)
(shell-script-lexer p))
(let loop ((lexeme (next)) (check 0))
;;(format #t "~S\n" lexeme)
(cond ((eq? ' (car lexeme)))
((eq? 'ignored (car lexeme))
(loop (next) check))
((and (< check expected-length)
(not (equal? (list-ref expected check)
lexeme)))
(error (format #f "expected ~S but got ~S !!!\n"
(list-ref expected check)
lexeme)))
(else
(loop (next) (1+ check)
;;; lex.test ends here
stamp-vti prerequisites
greetings, can someone suggest a way to regen stamp-vti based on changes to a file besides configure.ac? i see this in am/vers-texi.am: ## Depend on %CONFIGURE-AC% so that version number updates cause a ## rebuild. $(srcdir)/stamp-%VTI%: %TEXI% $(top_srcdir)/%CONFIGURE-AC% this is fine if version info is kept in configure.ac. however, in the case where configure.ac gets version info elsewhere (say, by sourcing VERSION, a shell script fragment), stamp-vti is not updated correctly. wouldn't it be better to just use configure itself as the prerequisite? that would behave correctly for both these cases and still fulfill the spirit of the comment. would that cause problems elsewhere? could this be changed for next automake release? thi
Re: installing config.h
Bruce Korb <[EMAIL PROTECTED]> writes: http://ac-archive.sf.net/Miscellaneous/ac_create_prefix_config_h.html thanks for the tip. fwiw, to try this i had to substitute AC_ECHO_MKFILE(foo,bar) with echo 'foo' > bar (the AC_ECHO_MKFILE from the website is empty.) thi
Re: installing config.h
Thien-Thi Nguyen <[EMAIL PROTECTED]> writes (imprecisely): you can process the headers on install. sorry, i forgot to emphasize: the headers processed are those other than config.h -- the horrible approach described does not require you to install config.h. (did i mention that this approach is very much Not Recommended but only posted for let-us-learn-from-this-foolish-example-of-badness reasons? :-) thi
Re: installing config.h
Waldemar Rosenbach <[EMAIL PROTECTED]> writes:
Is there another way to solve this kind of problem?
well, it's not clean, but you can process the headers on install. this could
be a provisional approach (i.e., kludge) while you make the interface platform
independent.
see below for petrify-headers. sample usage:
install-data-hook:
$(srcdir)/petrify-headers $(srcdir) $(pkginclude_HEADERS)
files=`ls *.petrified | sed 's/.petrified$$//g'`; \
for f in $$files ; do \
$(INSTALL_DATA) $$f.petrified $(DESTDIR)$(pkgincludedir)/$$f ; done
rm -f *.petrified
you will need to munge things slightly to fit your setup, or better yet, reel
in horror and run away run away!
thi
___
#!/bin/sh
# Usage: petrify-headers SRCDIR [FILE ...]
#
# Description: Scan scmconfig.h and then for each SRCDIR/FILE ...
# write ./FILE.petrified
if [ x"$1" = x ] ; then
echo 'ERROR: no srcdir specified'
exit 1
fi
srcdir=$1 ; shift
if [ x"$1" = x ] ; then
echo 'ERROR: no files specified'
exit 1
fi
one_syms=`awk '/^#define /{print $2}' scmconfig.h`
zero_syms=`awk '/^...#undef/{print $3}' scmconfig.h`
# first construct sed script
display_sed_script ()
{
echo 's,#include "libguile/scmconfig.h",,g'
for sym in $one_syms ; do
echo 's,^# *if\(def\)* '"$sym"'$,#if 1 /* petrified '"$sym"' */,g'
done
for sym in $zero_syms ; do
echo 's,^# *if\(def\)* '"$sym"'$,#if 0 /* petrified '"$sym"' */,g'
done
}
script=petrify-headers.sed
changed=petrify-headers.changed
unchanged=petrify-headers.unchanged
display_sed_script > $script
rm -f $changed $unchanged
touch $changed $unchanged
for f in "$@" ; do
sed -f $script $srcdir/$f > $f.petrified
if diff -q $srcdir/$f $f.petrified >/dev/null 2>&1 ; then
rm $f.petrified ; echo $f >> $unchanged
else
echo $f >> $changed
fi
done
rm -f $script
wc -l $changed $unchanged
rm -f $changed $unchanged
# petrify-headers ends here
Re: conditional subdir handling
Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: Amusingly this topic was discussed here last week, and we updated the manual while we were at it. Here is the resulting section of the manual (this text will go into Automake 1.7, but it applies to 1.6.x as well). Fell free to suggest improvements! thanks for the quick reply! i now see that the discussion happened in automake-patches, so i'll remember to expand my search to include that list, next time. the docs are very good; only suggestion would be to add a "see below" to this paragraph: As you can't see, running `make dist' will recurse into both `src/' and `opt/' directories because `make dist', unlike `make all', doesn't use the `SUBDIRS' variable. It uses the `DIST_SUBDIRS' variable. alternatively, you could move the various DIST_SUBDIRS snippets to node "Dist" and use xrefs. thi
conditional subdir handling
hi automake folks, i would like to have SUBDIRS = a b c D but control recursion into D via a configure.in "enable_D" var. any hint would be appreciated. if there's a recommended way, i'll write it up and submit a doc patch. the docs (autoconf/automake) don't mention "conditional subdirs" like this, although they both describe unconditional subdir handling. a scan through automake list archives 1-yr back for subject "subdir" did not show anything relevant. thi
Re: depcomp for texinfo + automake in guile
Tom Tromey <[EMAIL PROTECTED]> writes: It would be nice to let other tools that generate dependencies well integrate into automake seamlessly. presumably "well" means "following depcomp protocol", i.e., the transformer for foo.a to foo.b needs to by side effect create .deps/foo.Pb, in which case automake can generate the "include .deps/foo.Pb" and code to seed them at configure-time w/ "# dummy"? given this, the integration point would lie in generalizing recognition of those directives that trigger inclusion of depcomp machinery, and making that machinery tabular. a conforming tool would need to have installed appropriate support .am from which to draw the machinery, prior to use, of course. also, automake would not need to be so stringent about requiring all .b prerequisites to be statically declared. let me know if these guesses are close to the mark and if you'd be willing to consider a patch to explore such changes. (if not, no big deal.) thi
depcomp for texinfo + automake in guile
hi automake folks,
in the version of guile i'm munging, i decided to generate texinfo from
scanned source snippets, i.e.:
.scm -> .doc -> .doc-index -> .texi
.c -> .doc (or .cdoc) -> .doc-index -> .texi
this is not a simple concatenation, however. .texi is actually made
from .twerp ("texi with eval-requiring predelictions", yuk yuk) files
that are mostly texinfo w/ some
@twerpdoc (foo-proc (C scm_foo_proc))
style directives. these are expanded by a program (twerp2texi, q.v.[1])
which consults the .doc-index files, and as a side effect also creates
under the builddir .deps/foo.Ptexi (naming inspired by depcomp) so that
later changes to .scm or .c trigger .texi rebuild.
i could not find ready documentation (automake 1.6.1) on how to emulate
the "include .deps/foo.Ptexi" since, if i add that to Makefile.am, it
seems automake interprets that for itself instead of passing it through
to the end Makefile. the workaround is to have configure run a program
after invoking config.status to do the job. is there a better way?
in any case, the methodology works[1] but only by sidestepping automake
in a few places. my question is: is there a canonical way to do this
w/in the automake worldview that i've not yet discovered? if not, what
would be the best way to contribute general handling of .texi generation
to automake?
the other top-level question is: i noticed "automake in guile per rms
request" in a todo list (somewhere). has anyone started that? if not,
is anyone in the audience interested in funding that work?
thanks in advance for any insights (and thanks for automake!).
thi
[1] http://www.glug.org/tmp/2002-08/guile-1.4.1.3.20020810.tar.gz
(work in progress; not all doc/ref/*.twerp files have directives.)
Re: guile.m4 documentation
From: Bruce Korb <[EMAIL PROTECTED]> Date: Fri, 04 Jan 2002 21:47:43 -0800 manual dependencies [...] ^^ probably find a lot of these in docs/Makefile.am (yuk yuk ;-). thi
