Re: [RFC] improving support for building native tools in cross setups
Yann Dirson ydir...@free.fr writes: It is not uncommon for software packages to build tools to be executed at build time, to generate data files or more input files to compile. ... For the second point, it would seem a good idea at some point to support a native_ prefix, so setting eg. native_PROGRAMS will trigger the use of BUILD_* tools. I am no longer particularly familiar with automake internals, but I do think some sort of this is for the build machine is a very good idea. At the risk of descending into bikeshedding, I'm not sure that native_ is the best option, because just about everything that is foo_PROGRAMS describes something built from native code. build_ isn't great either (despite the symmetry with AC_CANONICAL_BUILD c.) because most of what automake does involves building programs. But I am glad to see this being worked on. -- Jack
bug#13588: Pax hangs in case big UID
Hi Petr, I have a couple of observations: - AC_MSG_ERROR is going to stop the configure anyway, so you don't need exit 1. - I'd suggest the following messages for your AC_MSG_ERRORS: the uid is too large for ustar-format tarfiles. Change format in configure.ac the gid is too large for ustar-format tarfiles. Change format in configure.ac - Is there a reason you've gone with test -ge 2097152 instead of test -gt 2097151? - Test for $1 = ustar first, so you only AC_CHECK_PROG for id when needed. - You could merge some of those nested tests: if test $? -eq 0 -a $user_id -gt 2097151; then AC_MSG_ERROR([...]) fi - That argument can be conditionally expanded at m4 time, so it'll be a bit faster for end users to use an m4 conditional here. - In fact, you might want to structure it like this: m4_if($1, [ustar], [AC_CHECK_PROG([am_prog_have_id], [id], [yes], [no]) if test x$am_prog_have_id = xyes; then AC_MSG_CHECKING([if uid is small enough for ustar]) user_id=`id -u` if test $? -eq 0 -a $user_id -gt 2097151; then AC_MSG_RESULT([yes]) else AC_MSG_RESULT([no]) AC_MSG_ERROR([...]) fi AC_MSG_CHECKING([if gid is small enough for ustar]) group_id=`id -g` if test $? -eq 0 -a $group_id -gt 2097151; then AC_MSG_RESULT([yes]) else AC_MSG_RESULT([no]) AC_MSG_ERROR([...]) fi fi]) But that's just my opinion, and Stefano's the one who vets the patches around here. Stefano: is this the sort of thing that should have AC_MSG_CHECKING/AC_MSG_RESULT pairs? Also, have I got the m4 quoting right? -- Jack Petr Hracek phra...@redhat.com writes: Hello Stefano, diff --git a/m4/tar.m4 b/m4/tar.m4 index ec8c83e..87477f1 100644 --- a/m4/tar.m4 +++ b/m4/tar.m4 @@ -81,6 +81,27 @@ do AM_RUN_LOG([tardir=conftest.dir eval $am__tar_ conftest.tar]) rm -rf conftest.dir if test -s conftest.tar; then +AC_CHECK_PROG([ID_TEST], id, [yes], [no]) +if test x$ID_TEST = xyes; then + if test x$1 = xustar ; then + user_id=`id -u` + if test $? -eq 0; then + # Maximum allowed UID in case ustar format is 2097151. + if test $user_id -ge 2097152; then + AC_MSG_ERROR([The uid is big and not allowed in case of ustar format. Change format in configure.ac],[2]) + exit 1 + fi + fi + group_id=`id -g` + if test $? -eq 0; then + # Maximum allowed GID in case ustar format is 2097151 + if test $group_id -ge 2097152; then + AC_MSG_ERROR([The gid is big and not allowed in case of ustar format. Change format in configure.ac],[2]) + exit 1 + fi + fi + fi +fi AM_RUN_LOG([$am__untar conftest.tar]) grep GrepMe conftest.dir/file /dev/null 21 break fi I would like to help you so that all issues like style, commit message,will be properly set. If you agree I will commit that patch in accordance GNU coding style and HACKING file. Best regards Petr On 02/05/2013 02:51 PM, Stefano Lattarini wrote: Hi Peter and Petr (no typo :-) FYI, this patch is on my radar, and I intend to consider it (and likely integrate and adjusted version of it) in the upcoming minor version of Automake (1.13.2). If you want to speed things up a bit and make the integration work easier to us, you can present the patch as the output of git format-patch rather than of git diff, and add a clear git commit message that explains the rationale and motivation for the change. That would be appreciated. On 02/05/2013 01:42 PM, Petr Hracek wrote: Hello Peter, no problem, I will wait. AC_SUBST is used for one place instance of the variable so that we will modify (in future) only one row instead of several. I don't understand this rationale; and I agree with Peter that the AC_SUBST call on AM_BIG_ID is unneeded; this should be just a shell variable (and since it is used only internally by the automake generated code, it should likely be renamed to something like 'am_big_id', or even '_am_big_id'. There are other issues too, but I'll get to them when I'll do a proper review. I hope that this is not too much general. BR Petr Thanks, Stefano
bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
Diego Elio Pettenò flamee...@flameeyes.eu writes: On 31/01/2013 20:58, Jack Kelly wrote: IMHO, that seems like a great way to cause trouble for unsuspecting users. (Anyone remember KDE4.0?) Can you expand on why you think it's a good plan? Because unlike KDE, automake can put a big fat warning in the generated configure that says You're using a version unsuitable for production, and then people would understand it much better. Or at automake invocation time? KDE 4.0 was a screwup because there was no big fat warning, and users insisted to have it. No user _asks_ for automake. Is there a system like X.beta1, X.beta2, ..., X.0 that is going to fit the ordering system for most package managers? Bonus points if it works in asciibetical order, too. Good luck finding one. Gentoo would be fine with X.Y_betaZ — but I honestly dislike X.Yb because that kind of stuff is usually _after_ X.Y for almost everything but autotools.. Fair points. +1 to calling the betas X.0. -- Jack
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
Diego Elio Pettenò flamee...@flameeyes.eu writes: Okay that sounds reasonable. I would be more toward 24 than 18 — maybe going for 18 to the next beta-quality automake, 24 to the final release. Speaking of which I would suggest that we call X.0 the betas, and suggest general usage only when X.1 is out... IMHO, that seems like a great way to cause trouble for unsuspecting users. (Anyone remember KDE4.0?) Can you expand on why you think it's a good plan? Is there a system like X.beta1, X.beta2, ..., X.0 that is going to fit the ordering system for most package managers? Bonus points if it works in asciibetical order, too. -- Jack
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
Diego Elio Pettenò flamee...@flameeyes.eu writes: On 31/01/2013 20:58, Jack Kelly wrote: IMHO, that seems like a great way to cause trouble for unsuspecting users. (Anyone remember KDE4.0?) Can you expand on why you think it's a good plan? Because unlike KDE, automake can put a big fat warning in the generated configure that says You're using a version unsuitable for production, and then people would understand it much better. Or at automake invocation time? KDE 4.0 was a screwup because there was no big fat warning, and users insisted to have it. No user _asks_ for automake. Is there a system like X.beta1, X.beta2, ..., X.0 that is going to fit the ordering system for most package managers? Bonus points if it works in asciibetical order, too. Good luck finding one. Gentoo would be fine with X.Y_betaZ — but I honestly dislike X.Yb because that kind of stuff is usually _after_ X.Y for almost everything but autotools.. Fair points. +1 to calling the betas X.0. -- Jack
Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
Stefano Lattarini stefano.lattar...@gmail.com writes: So I propose the following change in the Automake versioning scheme: * Major releases should actually have the major version number bumped. That is, the next major Automake version will be 2.0, rather than 1.14; and the major version after that will be 3.0; and so on. After all, there is no shortage of integer numbers to use :-) Such major releases can introduce backward-incompatibilities (albeit such incompatibilities should be announced well in advance, and a smooth transition plan prepared for them), and try more risking and daring refactorings. * Minor releases have the minor version number bumped (1.13 - 1.14 - 1.15 ...), can introduce new safe features, do non-trivial but mostly safe code clean-ups, and even add new runtime warnings (rigorously non-fatal); but they shouldn't include any backward incompatible change, nor contain any potentially destabilizing refactoring or sweeping change, nor introduce new features whose implementation might be liable to cause bugs or regressions in existing code. * Micro releases (1.14.1, 1.14.2, ...) should be just bug-fixing releases; no new features should be added, and ideally, only trivial bugs, recent regressions, or documentation issues should be addressed here. This sounds quite resonable to me, but is there anyone who is relying on automake versions taking the form 1.x.y? It might be worth reaching out to the distro packagers, just in case. -- Jack
Re: [IMPORTANT] Should I stop flooding the list with patches?
Stefano Lattarini stefano.lattar...@gmail.com writes: So I ask: do you think it would be worthwhile to curb the quantity of patches posted here, by posting only the patches judged worth of general interest? Or, if that sounds overly harsh, what should I/we do to ensure important changes have more visibility? I like the situation as it is. I'm an occasional commentator and a very occasional contributor, so take my opinion with some salt. It's easier for readers to filter the list in a way that makes sense to them, because one developer's deprecation of a misfeature can easily become a user's sudden breaking change. I'm not saying this is done on purpose, but it's easy for it to accidentally happen. Perhaps a severity tag in the subject line is the answer? -- Jack
Re: automake and pyconfigure: a future integration?
Kerrick Staley m...@kerrickstaley.com writes: Really, I'd just like to get gobject-introspection to compile on Arch Linux. The problem is that gobject-introspection's configure.ac has the line AM_PATH_PYTHON([2.5]) but gobject-introspection can't actually work with Python 3 or higher (the default on Arch); it needs Python 2. Automake doesn't seem to provide a way to specify this need. If you're just building gobject-introspection, then ./configure PYTHON=/usr/bin/python2 is the way to go. If you're trying to fix gobject-introspection, then perhaps the solutions offered at http://stackoverflow.com/questions/4619664/autofoo-test-for-maximum-version-of-python may help? -- Jack
Re: [PATCH] AM_PATH_PYTHON: try python2 et al. first
Kerrick Staley m...@kerrickstaley.com writes: Usually, when AM_PATH_PYTHON is invoked with an argument of the form 2.X, it means that only a Python 2 interpreter should be used, and not a Python 3 interpreter. However, the python command invokes a Python 3 interpreter on some systems (see [1]), so if we try python first, we may get a Python 3 interpreter when really a Python 2 interpreter is needed. By changing the precedence so that the python2(.X) commands are tried first, a Python 2 interpreter will always be used if one is available (and of sufficiently high version). [1] http://www.python.org/dev/peps/pep-0394/ I disagree with this patch. The Future Changes to this Recommendation section of PEP 394 anticipates changing the `python' symlink to `python3' at some point in the future. I think a better patch would change the search list based on the major version passed as the first argument to AM_PATH_PYTHON: a) If it's 2.x, search `python2 python2.7 python2.6 ... python'. b) If it's 3.x, search `python3 python3.3 python3.2 python3.1 ... python'. c) If nothing's given, search `python python2 python2.7 ... python2.0 python3 python3.2 ... python3.0.' In case (c), swap the search order to search python3 interpreters first once PEP 394 updates its recommendation to make python symlink to a python 3 interpreter. Question: should this dispatch be done at `autoconf' time (via m4) or at `./configure' time (via sh)? If a package wants to support python 2 and 3, I think they should inspect $PYTHON after a call to AM_PATH_PYTHON, and not pass a shell variable as the first argument. Is there an automake convention about which arguments can safely hold shell variables? -- Jack
bug#12620: Parallel tests vs fast tests (and beyond)
On Thu, Oct 11, 2012 at 6:53 AM, Reuben Thomas r...@sc3d.org wrote: This whole problem is an instance of a more general problem, of which another example is parallel make: for best performance, it should probably batch up calls to gcc, for example, so that multiple source files are compiled by each invocation. We had a discussion along these lines when refactoring elisp compilation: in the past it was all done in one big batch. Now it's done with an emacs invocation per .el file. The result of that discussion was that while you slow down single core machines, the new way of doing things fits make's model much better: instead of fiddling around with stamp files, the Makefile just has a suffix rule. IMHO, your point is valid, but to do it safely would require a tool smarter than make. -- Jack
Re: [PATCH 1/2] AC_CONFIG_MACRO_DIR: accept more than one argument
On Fri, Sep 21, 2012 at 12:53 AM, Stefano Lattarini stefano.lattar...@gmail.com wrote: Another ping. Automake 1.13 will need to know the interface of this new Autoconf feature in order to integrate with it correctly, and start deprecating ACLOCAL_AMFLAGS (in documentation only until Autoconf 2.70 is out; after that, also with warnings in the 'obsolete' category). I've been out of the loop on this one, but if ACLOCAL_AMFLAGS is going to go away, how do you specify that you want to pass --install to aclocal? -- Jack
Re: Refactoring elisp compilation
On Mon, Jul 23, 2012 at 10:16 PM, Stefano Lattarini stefano.lattar...@gmail.com wrote: On 07/23/2012 01:26 PM, Jack Kelly wrote: I think the way to do this would be as an improvement to make batch mode more palatable in general. I think an environment variable or a change to default behaviour is the least-potentially-breaking solution. Good. Do you fancy bringing this up on the Emacs list? As I said, no need to hurry. Done: http://lists.gnu.org/archive/html/help-gnu-emacs/2012-08/msg00071.html If that doesn't work, I'll look into writing a patch. I can do this. If you can find an autoconfiscated package that makes a deeper and more complex use of Emacs lisp than Autoconf does, and test with that, it would be great. I have not yet done this. I will send a note to myself and try to do this in the next day or so. -- Jack
bug#12058: AM_PATH_SDL does not find SDL framework installations on Mac OSX
On Fri, Jul 27, 2012 at 4:38 AM, Stefano Lattarini stefano.lattar...@gmail.com wrote: IMNSHO that choice of a name it is a serious mistake by whoever is defining/distributing that macro, for two reasons: 1. it gives the wrong impression that the macro is provided by or related to Automake -- not true. 2. It invades the 'AM_' namespace, that should be reserved for automake macros. IIRC a number of packages used to define their own AM_PATH_FOO macros, all subtly different. This is before pkg-config came about, and before the AX_ namespace was widely used (available?). Back to you problem: a google search *suggests* that AM_PATH_SDL is provided by the SDL project itself: http://wiki.libsdl.org/moin.cgi/FAQLinux http://lists.libsdl.org/pipermail/commits-libsdl.org/2010-April/002622.html http://www.libsdl.org/release/SDL-1.2.15/sdl.m4 I don't have a mac handy so I can't go rummaging around in the .dmg, but if there's a sdl-config in the framework you've installed, you make be able to get freeciv to configure by passing an appropriate --with-sdl-prefix flag. So if you can make it configure, then the bug is with sdl.m4, which should be looking for frameworks on OSX, I suppose. You may be able to make it work with pkg-config (replace the call to AM_PATH_SDL with an appropriate PKG_CHECK_MODULES call), depending on whether the framework distributes sdl.pc and your PKG_CONFIG_PATH.
Re: Refactoring elisp compilation
On Tue, Jul 17, 2012 at 7:04 PM, Stefano Lattarini
stefano.lattar...@gmail.com wrote:
Maybe we could try to write to the Emacs list for help at this point...
I wrote the emacs list, and they pointed me to the NOMESSAGE argument
for (load). Unfortunately the rabbit hole goes deeper...
Emacs defines a variable, site-run-file, that is meant to be the
first thing loaded, before .emacs and before default.el. We can get
at that, but not with -Q. An autoconf check seems the correct approach
here (as part of AM_PATH_LISPDIR), running something like:
$(EMACS) -batch --eval (princ site-run-file) 2/dev/null
(Is the redirect to /dev/null safe for DJGPP and/or MSYS?)
Because debian has to do things their own way, (I'm sure they have
their reasons), the initialisation process on debian systems is a
little more complicated than just running the site-run-file:
http://stackoverflow.com/q/189291/429232
Therefore, we can check if it's a debianised emacs with something like:
$(EMACS) -batch --eval (unless (boundp 'debian-emacs-flavor) (kill-emacs 1))
And we can get the actual flavour with this:
$(EMACS) -batch -eval (princ debian-emacs-flavor) 2/dev/null
It is fairly easy to advise (load) so that it's always loading silently:
(defadvice 'load ('before 'silently) (ad-set-arg 2 t))
(ad-activate 'load)
Then the next step is to emulate the normal startup, which would be
something like:
(let ((debian-emacs-flavor (quote $flavor)) (site-run-file \$sitefile\))
(when (debian-emacs-flavor)
(load \debian-startup\)
(debian-startup debian-emacs-flavor))
(load site-run-file))
At this point, we're well beyond what's sensible for a makefile
snippet, so we should really move it all into a .el file that lives in
$auxdir or a shell script with the elisp embedded. Do you have a
preference? I suppose a .el file saves an extra fork per .el file, and
I think there's sufficient command-line handling built into emacs that
it shouldn't be too hard to write a compile.el or el-compile.el (do
you have a name to suggest?).
-- Jack
Re: Refactoring elisp compilation
Overall, I think the correct action is to set aside this silent-rules
wild-goose-chase.
On Mon, Jul 23, 2012 at 7:26 PM, Stefano Lattarini
stefano.lattar...@gmail.com wrote:
On 07/23/2012 10:29 AM, Jack Kelly wrote:
On Tue, Jul 17, 2012 at 7:04 PM, Stefano Lattarini
stefano.lattar...@gmail.com wrote:
Maybe we could try to write to the Emacs list for help at this point...
I wrote the emacs list, and they pointed me to the NOMESSAGE argument
for (load). Unfortunately the rabbit hole goes deeper...
Emacs defines a variable, site-run-file, that is meant to be the
first thing loaded, before .emacs and before default.el. We can get
at that, but not with -Q. An autoconf check seems the correct approach
here (as part of AM_PATH_LISPDIR), running something like:
$(EMACS) -batch --eval (princ site-run-file) 2/dev/null
OK, so far sounds simple and sensible.
(Is the redirect to /dev/null safe for DJGPP and/or MSYS?)
For MSYS, yes. For DJGPP, I think so (/dev/null redirections are used
throughout the Automake codebase, and nobody has ever complained about
them), bot honestly I don't deeply care: DJGPP should be considered
obsolete anyway.
Because debian has to do things their own way, (I'm sure they have
their reasons), the initialisation process on debian systems is a
little more complicated than just running the site-run-file:
http://stackoverflow.com/q/189291/429232
Ouch.
Therefore, we can check if it's a debianised emacs with something like:
$(EMACS) -batch --eval (unless (boundp 'debian-emacs-flavor) (kill-emacs
1))
And we can get the actual flavour with this:
$(EMACS) -batch -eval (princ debian-emacs-flavor) 2/dev/null
It is fairly easy to advise (load) so that it's always loading silently:
(defadvice 'load ('before 'silently) (ad-set-arg 2 t))
(ad-activate 'load)
Then the next step is to emulate the normal startup, which would be
something like:
(let ((debian-emacs-flavor (quote $flavor)) (site-run-file \$sitefile\))
(when (debian-emacs-flavor)
(load \debian-startup\)
(debian-startup debian-emacs-flavor))
(load site-run-file))
Yikes :-(
I strongly fear this poking in Debian internals is too fragile w.r.t.
forward compatibility. I'd rather avoid further debacles like the
install-info one:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=213524
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9773
At this point, we're well beyond what's sensible for a makefile
snippet, so we should really move it all into a .el file that lives in
$auxdir or a shell script with the elisp embedded. Do you have a
preference? I suppose a .el file saves an extra fork per .el file,
My preference thus go to a '.el' file that lives in $auxdir. But first
I'd have to be convinced that catering to the Debian setup is actually
a good move. That won't be easy ;-)
OK, let's take a step back.
Are we sure that Emacs doesn't offer any way to pass early code fragments
to be eval'd before anything else not in the Emacs core is read or executed?
That would be great, and allow us to implement a much simpler and more
portable workaround.
I don't think so. before-init-hook looked promising, but you can't add
to that hook until after command-line options are parsed and dealt
with (too late). The only way to change it with real effect is before
dumping Emacs. (
http://www.gnu.org/software/emacs/manual/html_node/elisp/Init-File.html
). Dumping an updated emacs into $builddir seemed promising, but
calling (dump-emacs newmacs /usr/bin/emacs) is just causing
segfaults on my machine.
Even better: maybe Emacs offers an environment variable that could be used
to control the verbosity of (load), and maybe of other functions as well?
Something akin to PYTHONVERBOSE for python:
http://docs.python.org/release/3.1.5/using/cmdline.html#envvar-PYTHONVERBOSE
If this is not the case, could such a variable be added to future Emacs
version? This way, our elisp byte-compile rules would be kept simple,
with only the (IMHO minor) annoyance that silent rules wouldn't work very
well for them with non recent emacs versions. And this annoyance would
be automatically mitigated as the times goes by and non-very-recent Emacs
versions become first older, then old, and finally ancient.
I think the way to do this would be as an improvement to make batch
mode more palatable in general. I think an environment variable or a
change to default behaviour is the least-potentially-breaking
solution.
and
I think there's sufficient command-line handling built into emacs that
it shouldn't be too hard to write a compile.el or el-compile.el (do
you have a name to suggest?).
-- Jack
Finally, an update on the status of the 'elisp-work' branch: I plan to
add support for '$(EMACSFLAGS)' and '$(AM_ELCFLAGS)' being automatically
passed to our emacs invocations, add a couple of new test cases, and
then merge the branch into 'master'. Since the lack of 'silent-rules'
support
Re: Refactoring elisp compilation
On Sun, Jul 15, 2012 at 6:03 PM, Stefano Lattarini stefano.lattar...@gmail.com wrote: At least we should find a way to silence all messages that are not real warnings or errors... Otherwise, adding silent rules support would just be pointless. I have been asking about this on SO, and there has been a little progress towards a resolution: http://stackoverflow.com/q/11498108/429232 Look at the answer involving grep. Is there any portable way to grep away the loading messages without losing the exit status? -- Jack
elisp: --batch implies -q, so remove -q.
Hi automakers, I noticed that the --batch argument to emacs implies -q, so I patched out -q. Patch attached, which passes all lisp tests on my machine. Apply to experimental/elisp-work. -- Jack 0001-elisp-batch-implies-q-remove-q.patch Description: Binary data
Refactoring elisp compilation
Hi automakers,
I had a crack at refactoring the elisp compilation, getting rid of
elisp-comp and compiling files via a suffix rule. Patch is attached.
I am not submitting this for inclusion yet, I want to generate some
discussion first. I have the following concerns:
1. I would like to add silent-rules support, but it's not completely
straightforward. The call to file_contents is buried within
am_install_var. I'm thinking of adding another option to
am_install_var that adds a silent var to the file_contents call.
Something like am_install_var( '-silent_var=FOO', ...), which would
result in a call to define_verbose_tagvar('FOO') and AM_V_FOO =
verbose_flag('FOO') in the file_contents call.
2. If I implement (1) above, it's still not straightforward. The rules
will be invoked even if $(EMACS) = no, so the suffix rule guards
against that, becoming a no-op if $(EMACS) = no. That will be
rechecked by on every invocation of make, for every file in
$(ELCFILES). Perhaps an AM_CONDITIONAL in AM_PATH_LISPDIR is the way
to fix this? Existing tests shoudn't break because they set EMACS=no
either at configure time or in configure.ac.
3. On my Ubuntu system at least (and probably debian systems as well),
each call to emacs puts out a few messages of the form Loading
00debian-vars This isn't too bad, just unsightly. Any shell/elisp
wizards have a suggestion?
4. Instead of invoking emacs for all files at once, a new emacs is now
started for each .el file. This might make incremental builds faster,
one-time builds slower, both or neither. Does anyone know of projects
with a significant amount of elisp that I could test on?
Comments extremely welcome.
-- Jack
0001-Removes-elisp-comp-and-implements-elisp-compilation-.patch
Description: Binary data
Re: [PATCH 5/7] elisp: no need to absolutize $(srcdir) and $(builddir) ...
On Sun, Jul 15, 2012 at 7:51 AM, Stefano Lattarini stefano.lattar...@gmail.com wrote: * lib/am/lisp.am (.el.elc): ... here: we don't chdir around anyway, nor move or copy around our source '.el' files. Update comments, and re-wrap them while we are at it. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- lib/am/lisp.am | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/lib/am/lisp.am b/lib/am/lisp.am index ce87fb0..7326cb5 100644 --- a/lib/am/lisp.am +++ b/lib/am/lisp.am @@ -23,16 +23,17 @@ endif %?INSTALL% ## -- ## .el.elc: -## We add $(abs_builddir) and $(abs_srcdir) to load-path, so that any -## .el files that $ depends upon can be found (including generated -## ones). Prefer files from the build directory to those from the source -## directory, in true VPATH spirit. The destination file is normally -## determined by appending c to the input (which would erronously put -## it in $(srcdir) in VPATH builds), so we override that, too. +## We add $(builddir) and $(srcdir) to load-path, so that any '.el' files +## that $ depends upon can be found (including generated ones). +## We Prefer files from the build directory to those from the source Nit: Capital on `Prefer'. +## directory, in true VPATH spirit. +## The destination file is normally determined by appending c to the +## input (which would erronously put it in $(srcdir) in VPATH builds), so +## we override that, too. if test $(EMACS) != no; then \ $(EMACS) -q --batch \ - --eval (setq load-path (cons \$(abs_srcdir)\ load-path)) \ - --eval (setq load-path (cons \$(abs_builddir)\ load-path)) \ + --eval (setq load-path (cons \$(srcdir)\ load-path)) \ + --eval (setq load-path (cons \$(builddir)\ load-path)) \ --eval (defun byte-compile-dest-file (f) \$@\) \ --eval (unless (byte-compile-file \$\) (kill-emacs 1)); \ else :; fi -- 1.7.9.5
bug#11806: (setq load-path ..) of elisp-comp
On Fri, Jul 6, 2012 at 7:57 AM, Stefano Lattarini stefano.lattar...@gmail.com wrote: Usually I'd agree, and in fact I had done as you're suggesting in a previous attempt; but that caused the test 'lisp3.sh' to fail :-/ With the patch I've posted, the testsuite remains clean at least. So I say we commit my patch: albeit suboptimal, and somewhat reeking of cargo-cult programming, it solves the OP issue. I would like to have a crack at rewriting some of the elisp stuff, but I can make no promises as to when that will actually happen. Therefore I agree with you: commit the patch and we'll deal with the refactoring if/when it arrives. -- Jack
Re: bug#11806: (setq load-path ..) of elisp-comp
On Fri, Jul 6, 2012 at 7:57 AM, Stefano Lattarini stefano.lattar...@gmail.com wrote: Usually I'd agree, and in fact I had done as you're suggesting in a previous attempt; but that caused the test 'lisp3.sh' to fail :-/ With the patch I've posted, the testsuite remains clean at least. So I say we commit my patch: albeit suboptimal, and somewhat reeking of cargo-cult programming, it solves the OP issue. I would like to have a crack at rewriting some of the elisp stuff, but I can make no promises as to when that will actually happen. Therefore I agree with you: commit the patch and we'll deal with the refactoring if/when it arrives. -- Jack
bug#11806: (setq load-path ..) of elisp-comp
On Thu, Jun 28, 2012 at 8:49 PM, Stefano Lattarini stefano.lattar...@gmail.com wrote: On 06/28/2012 06:47 AM, Makoto Fujiwara wrote: I do have problem compiling *.el files with tc-2.3.1 (svn version) I think this is the relevant Makefile.am: http://code.google.com/p/tcode/source/browse/trunk/tc/lisp/Makefile.am It confuses me thoroughly. Could you expose such problems in a minimal test case? This way, I could add it to the automake testsuite, to ensure the issue doesn't represent itself in the future. Thanks. Following patch fixes this type of problem, thanks a lot. By the way, the same patch was once proposed as http://osdir.com/ml/sysutils.automake.patches/2003-01/msg4.html and fix seems to have made, but real line was dropped with unknown reason. --- lib/elisp-comp.orig 2012-06-01 22:47:10.0 +0900 +++ lib/elisp-comp 2012-06-28 13:28:44.0 +0900 @@ -75,7 +75,7 @@ ( cd $tempdir - echo (setq load-path (cons nil load-path)) script + echo (setq load-path (cons \../\ (cons nil load-path))) script $EMACS -batch -q -l script -f batch-byte-compile *.el || exit $? mv *.elc .. ) || exit $? The patch seems small and harmless, but unfortunately I know nothing at all about Lisp or Emacs, so I can't judge whether such a change could have unintended consequences. Perchance someone more knowledgeable than me in this area is reading the thread, and can chime in? Otherwise I will go ahead and push the patch in 72 hours. I'm no elisp master, but here's what I see is happening: * Developer defines something like lisp_LISP = foo.el bar.el baz.el * baz.el (say) depends on quux.el, in the same directory but not listed in the primary. * At `make' time, everything in lisp_LISP is copied to a subdirectory and batch-byte-compile is called on all those files. * Because quux.el wasn't copied over, the compile fails. * Adding the parent directory to load-path might fix that, but I wonder if it will still break on VPATH builds? Maybe the correct answer is to add ../$(srcdir) or $(abs_srcdir) insted. * Why (in the .el files) is the developer depending on a file that's not being compiled? will this cause automake to silently do the wrong thing if a new .el file has been listed and Makefile.am doesn't get updated? Now you can go ahead and install an incomplete package. * Should the current directory come before the source directory? There's another (potential) problem. The script that elisp-comp creates is called script. Does it make sense to allow files without a .el extension to appear in a _LISP primary? Currently, automake lets you get away with it, but it will only compile *.el anyway (even though it copies $@ into the temporary dir). I don't know enough about elisp to say, but if that's fixed, then script should be given a better filename (using mktemp or something) so it doesn't clobber a user's script. -- Jack
bug#11356: automake 1.12 and (C) 2011
On Fri, Apr 27, 2012 at 10:05 PM, Eric Blake ebl...@redhat.com wrote: On 04/27/2012 03:18 AM, Stefano Lattarini wrote: On 04/27/2012 05:30 AM, Peter Johansson wrote: +++ b/aclocal.in @@ -840,9 +840,8 @@ $output; # name in the header. $output = # generated automatically by aclocal $VERSION -*- Autoconf -*- -# Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, -# 2005, 2006, 2007, 2008, 2009, 2010, 2011 Free Software Foundation, -# Inc. +# Copyright (C) 1996-2012 Free Software Foundation, Inc. This makes sense, This took me by surprise, because it wasn't the case previously. It is now acceptable usage according to GNU standards, see http://savannah.gnu.org/forum/forum.php?forum_id=6576 and http://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html You can use a range (‘2008-2010’) instead of listing individual years (‘2008, 2009, 2010’) if and only if: 1) every year in the range, inclusive, really is a “copyrightable” year that would be listed individually; and 2) you make an explicit statement in a ‘README’ file about this usage. I suggest you update README to follow the guidelines. The guidelines don't say what exactly should be in the notice, but I presume it's a statement to the effect that 1) above holds. -- Jack
Re: bug#11356: automake 1.12 and (C) 2011
On Fri, Apr 27, 2012 at 10:05 PM, Eric Blake ebl...@redhat.com wrote: On 04/27/2012 03:18 AM, Stefano Lattarini wrote: On 04/27/2012 05:30 AM, Peter Johansson wrote: +++ b/aclocal.in @@ -840,9 +840,8 @@ $output; # name in the header. $output = # generated automatically by aclocal $VERSION -*- Autoconf -*- -# Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, -# 2005, 2006, 2007, 2008, 2009, 2010, 2011 Free Software Foundation, -# Inc. +# Copyright (C) 1996-2012 Free Software Foundation, Inc. This makes sense, This took me by surprise, because it wasn't the case previously. It is now acceptable usage according to GNU standards, see http://savannah.gnu.org/forum/forum.php?forum_id=6576 and http://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html You can use a range (‘2008-2010’) instead of listing individual years (‘2008, 2009, 2010’) if and only if: 1) every year in the range, inclusive, really is a “copyrightable” year that would be listed individually; and 2) you make an explicit statement in a ‘README’ file about this usage. I suggest you update README to follow the guidelines. The guidelines don't say what exactly should be in the notice, but I presume it's a statement to the effect that 1) above holds. -- Jack
bug#10226: Drop redundant Python 1.5 support?
On Tue, Dec 6, 2011 at 9:42 AM, Reuben Thomas r...@sc3d.org wrote: Reading python.m4, I notice that it claims to support only Python = 2.0, yet still has specific support for Python 1.5. Would a patch along the following lines therefore be accepted? (If so I'll write the changelog entry c.!) The patch appears mangled (at least for me). Can you send it to the list as an attachment? -- Jack
Re: bug#9088: Java support
On Mon, Jul 18, 2011 at 4:17 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: * Jack Kelly wrote on Sat, Jul 16, 2011 at 06:13:58AM CEST: On Sat, Jul 16, 2011 at 9:55 AM, tsuna wrote: On Fri, Jul 15, 2011 at 1:58 AM, Stefano Lattarini wrote: As my java foo is pretty weak, I'm not sure how to handle jar manifests, jar entry points, or other jar/javac subtleties and advanced features. Suggestions welcome. You can create the manifest manually fairly easily. Here's an example in the project I'm in the process of autotoolizing: https://github.com/stumbleupon/opentsdb/blob/6059488f38fc8a51d426d6972eee6fdd1033d851/Makefile#L207 Perhaps there should be support for a foo_jar_JARADD, that by analogy to _LDADD, that specifies additional files to be included in the jar? Why would it have to be a new primary, instead of just reusing _LDADD? Because, IMO, it's conceptually different. The output's being assembled with `jar', not `ld'. -- Jack
Re: bug#9088: Java support
On Sat, Jul 16, 2011 at 9:55 AM, tsuna tsuna...@gmail.com wrote: On Fri, Jul 15, 2011 at 1:58 AM, Stefano Lattarini stefano.lattar...@gmail.com wrote: As my java foo is pretty weak, I'm not sure how to handle jar manifests, jar entry points, or other jar/javac subtleties and advanced features. Suggestions welcome. You can create the manifest manually fairly easily. Here's an example in the project I'm in the process of autotoolizing: https://github.com/stumbleupon/opentsdb/blob/6059488f38fc8a51d426d6972eee6fdd1033d851/Makefile#L207 Perhaps there should be support for a foo_jar_JARADD, that by analogy to _LDADD, that specifies additional files to be included in the jar? Then the manifest is just another file. My Java-foo is also weak, so I'm not 100% sure if that would actually work. -- Jack
bug#9088: Java support
On Sat, Jul 16, 2011 at 9:55 AM, tsuna tsuna...@gmail.com wrote: On Fri, Jul 15, 2011 at 1:58 AM, Stefano Lattarini stefano.lattar...@gmail.com wrote: As my java foo is pretty weak, I'm not sure how to handle jar manifests, jar entry points, or other jar/javac subtleties and advanced features. Suggestions welcome. You can create the manifest manually fairly easily. Here's an example in the project I'm in the process of autotoolizing: https://github.com/stumbleupon/opentsdb/blob/6059488f38fc8a51d426d6972eee6fdd1033d851/Makefile#L207 Perhaps there should be support for a foo_jar_JARADD, that by analogy to _LDADD, that specifies additional files to be included in the jar? Then the manifest is just another file. My Java-foo is also weak, so I'm not 100% sure if that would actually work. -- Jack
bug#8881: config.h double inclusion
On Fri, Jun 17, 2011 at 6:29 AM, Paul Eggert egg...@cs.ucla.edu wrote: On 06/16/11 10:36, Alfred M. Szmidt wrote: I'm thinking that maybe config.h should be generated with a double inclusion guard But the general rule is that config.h must always be included first, no? So there shouldn't ever be a possibility of including it twice. It might be better to have config.h do something like this: #ifdef CONFIG_H # error config.h included twice #endif #define CONFIG_H Warning: Quite a few misbehaving packages actually install their config.h. -- Jack
bug#8665: automake should offer APIs to honour silent-rules verbosity from shell code in Makefiles
Comments inline, after some snipping. On Fri, May 13, 2011 at 6:27 AM, Stefano Lattarini stefano.lattar...@gmail.com wrote: -snip intro- I thus propose we add an API of this kind. At first, this might be as simple as just defining two proper `AM_V_ECHO' and `AM_Q_ECHO' variables; `AM_V_ECHO' should be `echo' when silent rules are in effect, and `:' when they are not; viceversa for `AM_Q_ECHO'. To give a simplified example of what I'm proposing: $ cat Makefile.am 'END' headers: @... [commands defining a shell variable `$headers']; \ $(AM_V_ECHO) cd somedir generate-header --flag $$headers; \ $(AM_Q_ECHO) GEN headers; \ cd somedir generate-header --flag $$headers If you're just echoing GEN headers, is there any reason you can't use $(AM_V_GEN) here? Maybe we should have a more general method of declaring silencing variables (like the $(AM_V_GEN), but also the others that echo 'CC' and friends. Then users who have unconventional setups can silence things without echoing 'GEN' everywhere. END $ autoreconf ... $ ./configure --disable-silent-rules ... $ make headers cd somedir generate-header --flag foo.h bar.h baz.h $ make headers V=0 GEN headers $ ./configure --enable-silent-rules ... $ make headers GEN headers $ make headers V=1 cd somedir generate-header --flag foo.h bar.h baz.h Or maybe we could start being more general from the beginning, and define a variable `AM_IS_SILENT' (say) that is defined to yes when silent rules are in effect, and to no otherwise. If you are going to do this, is it sufficient for it to be a variable, or does it need to be an AM_CONDITIONAL? I'm thinking a variable is fine. -- Jack
bug#8289: distcheck and make dvi
On Sun, Mar 20, 2011 at 10:53 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: Another possible change, in addition to messing with the documentation, would be to make the dvi a variable that such non-dvi-generating people can override with pdf if they wish. Then they could get the benefit of the check in a clean way without forcing .eps. Or maybe dvi: pdf would have the same effect? I'm not sure. Well, 'dvi: pdf' might help the distcheck to succeed, but generally, if I run 'make dvi' then what I'd like is DVI not PDF output. The latter is not convertible into the former. Enhancing distcheck to just not bother checking dvi output and rather test PDF output seems like another good alternative. Not only does this feel like a hack, but I'd worry that it might violate the GNU coding standards, to which automake-generated makefiles are meant to comply? -- Jack
bug#8111: after adding a(nother) subconfigure, rerunning make fails
On Sat, Feb 26, 2011 at 7:46 AM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: [ adding autoconf-patches; this is http://debbugs.gnu.org/8111 ] * Jack Kelly wrote on Thu, Feb 24, 2011 at 11:49:44PM CET: On Fri, Feb 25, 2011 at 6:36 AM, Ralf Wildenhues wrote: Can we fix this somehow in either Autoconf or Automake? Could we save the results of tracing AC_CONFIG_SUBDIRS calls? If there's a change, invoke ./config.status --recheck. If not, config.status --recheck --no-recursion. Well, the rule that invokes 'config.status --recheck', let's call it the config.status rule, does not invoke any autotools, thus no m4. Any rule that invokes m4 must be a developer rule, but the config.status rule is a user rule, which is even in place with maintainer-mode. So we cannot mix these two concepts. If they are changing `configure.ac', they will be invoking developer rules. I don't mean trace in the ./config.status --recheck rule, but instead at `automake' time: If there are any AC_CONFIG_SUBDIRS calls, write them out to a trace file (such as build-aux/subdirs.trace). Save the previous trace as build-aux/subdirs.trace.old. Now the rule to call config.status --recheck needs to only run `diff'. Having clarified myself, I think your method makes more sense (and has no additional files to dist). Comments on that below. Since 'makefile' might be spelt in various different ways, we can take presence of 'config.status' in the subdir build tree as indicator, that should be good enough. You should add a comment to this effect in your status.m4 changes. Currently, it looks like you've tested for config.status by mistake. I'm still wondering whether we should rename the option --new-recursion-only however, that would be more precise. Other than that, the patch below seems to do what I want. Yes. the name becomes very confusing. Maybe --recursion=no (with --no-recursion as an alias), --recursion=new-only? -- Jack
bug#8111: after adding a(nother) subconfigure, rerunning make fails
On Fri, Feb 25, 2011 at 6:36 AM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: Can we fix this somehow in either Autoconf or Automake? Could we save the results of tracing AC_CONFIG_SUBDIRS calls? If there's a change, invoke ./config.status --recheck. If not, config.status --recheck --no-recursion. -- Jack
bug#8104: automake suggests use of AC_PROG_LIBTOOL, this has been replaced by LT_INIT
Version: 1.11.1 (ubuntu 10.10). I have inspected the most recent master and it appears to also have this bug. configure.ac: AC_INIT([a], [b], [c]) AM_INIT_AUTOMAKE([foreign]) dnl no LT_INIT -- on purpose AC_PROG_CC AC_CONFIG_FILES([Makefile]) AC_OUTPUT Makefile.am: lib_LTLIBRARIES = libfoo.la Run autoreconf -i: $ autoreconf -i Makefile.am:1: Libtool library used but `LIBTOOL' is undefined Makefile.am:1: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' Makefile.am:1: to `configure.ac' and run `aclocal' and `autoconf' again. Makefile.am:1: If `AC_PROG_LIBTOOL' is in `configure.ac', make sure Makefile.am:1: its definition is in aclocal's search path. autoreconf: automake failed with exit status: 1 See the libtool manual ( http://www.gnu.org/software/libtool/manual/html_node/LT_005fINIT.html ): AC_PROG_LIBTOOL and AM_PROG_LIBTOOL are deprecated names for older versions of this macro; autoupdate will upgrade your configure.ac files. It appears that automake's message is out of date. -- Jack
bug#8044: Automake should support autotest-based testsuites.
On Wed, Feb 16, 2011 at 4:39 AM, Stefano Lattarini stefano.lattar...@gmail.com wrote: The steps required to set up an autotest-based testsuite are already excellently described in the autoconf manual: http://www.gnu.org/software/autoconf/manual/html_node/Making-testsuite-Scripts.html and seem pretty mechanical, so it shouldn't be too much difficult to teach automake how to reproduce them. Do you think that would be worthwhile? If yes, I might attempt an implementation (taking as references/inspiration the autoconf manual and autoconf's own tests/Makefile.am). I must warn you that that will probably take me some time, tough. It sounds useful for some (probably not me, though), but I'd be wary of the big warning at the start of the autotest section: N.B.: This section describes a feature which is still stabilizing. Although we believe that Autotest is useful as-is, this documentation describes an interface which might change in the future: do not depend upon Autotest without subscribing to the Autoconf mailing lists. -- Jack
Re: bug#7944: Should AM_PATH_PYTHON call AC_ARG_VAR?
On Tue, Feb 1, 2011 at 7:31 AM, Stefano Lattarini
stefano.lattar...@gmail.com wrote:
On Monday 31 January 2011, Jack Kelly wrote:
I've noticed that if you put AM_PATH_PYTHON in configure.ac, it
doesn't add an entry for PYTHON in ./configure --help. Is PYTHON meant
to be a user's variable?
According to the comments in `m4/python.m4' and to the tests
`python{4,6,11}.test', it is (and I think that's a good policy).
Documenting the fact in the configure help screen and in the
manual would be a good idea too. What about the attached patch?
Looks good to me, bar the following nit:
doc/automake.texi:
+If @var{action-if-not-found} is not specified, as in the following example
+, the default is to abort @command{configure}.
Should the comma be on the previous line?
BTW, Jack, are you the same Jack Kelly already listed in THANKS
(Jack Kelly endgame@gmail.com)? If yes, should we update
your e-mail address?
Yes I am, and yes please.
-- Jack
bug#7945: Is AM_PATH_PYTHON missing some versions in _AM_PYTHON_INTERPRETER_LIST?
(automake-1.11.1, ubuntu 10.10 package) Hi automakers, While poking around python.m4, I noticed that python2.6 and python2.7 are not mentioned in the list of python interpreters defined in _AM_PYTHON_INTERPRETER_LIST. Is this intentional? -- Jack
bug#7944: Should AM_PATH_PYTHON call AC_ARG_VAR?
Hi automakers, I've noticed that if you put AM_PATH_PYTHON in configure.ac, it doesn't add an entry for PYTHON in ./configure --help. Is PYTHON meant to be a user's variable? Minimal configure.ac: AC_INIT AM_PATH_PYTHON AC_OUTPUT -- Jack
bug#7621: add a way to pass link dependencies
On Sat, Jan 22, 2011 at 11:16 PM, Bruno Haible br...@clisp.org wrote: For (A), the list of options to be ignored during dependency extraction is the following (cf. gnulib/build-aux/config.rpath): -rpath /some/path -Wl,-rpath -Wl,/some/path -Wl,-rpath,/some/path -lopt=-rpath -lopt=/some/path -Qoption ld -rpath -Qoption ld /some/path -R/some/path -R /some/path -blibpath:/some/path -Wl,-blibpath:/some/path +b /some/path -Wl,+b -Wl,/some/path Should there be an -Xlinker option in this list, too? -- Jack
bug#7773: (lack of) config.h description in manual
I disagree that `make prefix=... install' is a poor man's DESTDIR. Installing using DESTDIR will install things in $(DESTDIR)/$(prefix)/bin (and so on), which is a right pain when it comes to using something like GNU Stow to manage /usr/local. -- Jack On Tue, Jan 4, 2011 at 6:13 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: Hello Karl, Eric, * Eric Blake wrote on Tue, Jan 04, 2011 at 01:33:42AM CET: On 01/03/2011 05:00 PM, Karl Berry wrote: Thanks for the reference. Now that I know it, I suggest the Automake manual simply have a sentence with an xref to that node. Yes, I agree with that, and I am still going to do that. You opened two bug reports originally (inadvertently), I only closed the one that was dealt with. Sorry if that was unclear before. Hmm, I'm not so sure that the GCS forbids doing the right thing (or that it has to stay that way even if it does), but I won't pursue it further. What the GCS requires is that you can do 'make prefix=/alternate/path' and have that propagate through all the directory variables. Anything learned at configure time can thus be rewritten at make time, so the only safe place to record a directory variable's value is at make time. I don't think this aspect of the GCS needs changing. One other thing to point out is that the GCS documents that 'make install' should ideally not rebuild any source code, but that this ideal is only possible if you either _don't_ use 'make prefix=...', or if you use the same prefix in both 'make prefix=...' and 'make install prefix=...'. I don't think that is correct. In fact, I think it is entirely intended to be possible to use a different prefix= setting for the all and for the install targets, and the latter should still not rebuild sources. Sort of a poor-man's DESTDIR. You can see the usefulness on MSYS and DJGPP (where DESTDIR does not work due to drive prefix concatenation). (Of course Libtool doesn't support the non-DESTDIR way, but that's another story ...) Cheers, Ralf
bug#7655: conditional _TEXINFOS should be supported
On Fri, Dec 17, 2010 at 6:09 AM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote:
if COND
info_TEXINFOS = foo.texi
foo_TEXINFOS = bar.texi
nodist_info_TEXINFOS = generated.texi
endif
should work to generate and install foo.{info,pdf,...} only if COND,
but distribute foo.texi and bar.texi always. Similar with
generated.texi (except for distribution, of course).
Disagree. foo.info should always be built, because it goes into `make
dist'. If you want to limit building for non-specific `make', then
make sure that the .info files and such all depend on `make dist', so
the tarball is correctly generated.
Agree with the remarks about not making pdfs, dvis and inhibiting
their installation.
-- Jack
bug#7562: automake-set variables don't get properly reordered when overriden in Makefile.am
Remark: This may be unrelated. I don't know about overriding in Makefile.am, but overriding $(prefix) is important for supporting GNU Stow. To set up a package for Stow, you configure for one prefix and install under another (note that this isn't the same as using $(DESTDIR) - that dumps the whole directory tree under the target path). Example: ./configure --prefix=$HOME make make prefix=$HOME/stow/foo-x.y.z cd $HOME/stow stow foo-x.y.z So whatever you do with the variable ordering, I hope it doesn't break overrides from the command line. -- Jack On Mon, Dec 6, 2010 at 4:34 AM, Stefano Lattarini stefano.lattar...@gmail.com wrote: Severity: wishlist This issue was brought up by Ralf Wildenhues in a thread on automake-patches. Automake generally orders all of its variable settings before all of the user ones (so the user ones are preferred). But when one overrides e.g. bindir in a Makefile.am, that variable doesn't get reordered to the user part, because it is actually automake-set before it is overridden. The issue is exposed in the attached testcase. It's still not clear to me whether this is a bug or a feature, but I thought that entering it into the Automake bug database would be a good idea anyway. Regards, Stefano #! /bin/sh # Test that := definitions work as expected at make time, even when # whey involve user-overridden automake-set variables. # # Currently, this test doesn't work, because automake generally orders # all of its variable settings (e.g. bindir and the like) before all # of the user ones. Even when bindir is overridden, it doesn't get # reordered to the user part. Might this be considered an automake bug? required=GNUmake . ./defs || Exit 1 set -e cat configure.in 'END' AC_OUTPUT END cat Makefile.am 'END' BAR := $(bindir) BAZ = $(bindir) bindir = foo .PHONY: test test: test x'$(bindir)' = x'foo' test x'$(BAZ)' = x'foo' test x'$(BAR)' = x END $ACLOCAL $AUTOCONF $AUTOMAKE -Wno-portability ./configure $MAKE test :
bug#7562: automake-set variables don't get properly reordered when overriden in Makefile.am
On Mon, Dec 6, 2010 at 7:50 AM, Stefano Lattarini stefano.lattar...@gmail.com wrote: On Sunday 05 December 2010, Jack Kelly wrote: Remark: This may be unrelated. I don't know about overriding in Makefile.am, but overriding $(prefix) is important for supporting GNU Stow. To set up a package for Stow, you configure for one prefix and install under another (note that this isn't the same as using $(DESTDIR) - that dumps the whole directory tree under the target path). Example: ./configure --prefix=$HOME make make prefix=$HOME/stow/foo-x.y.z cd $HOME/stow stow foo-x.y.z So whatever you do with the variable ordering, I hope it doesn't break overrides from the command line. Oh, it must absolutely not break that, since the behaviour you want is mandated by the GNU coding standards, and cannot be changed. Breaking it would be a *grave* automake bug. So I guess you're safe in this respect. I'm glad you're on top of that. I just wanted to bring it up in case it had been forgotten. Thanks. -- Jack
Re: need to set ACLOCAL_AMFLAGS along with AC_CONFIG_MACRO_DIR
On Thu, Sep 16, 2010 at 6:11 AM, Eric Blake ebl...@redhat.com wrote: On 09/15/2010 12:59 PM, Ralf Wildenhues wrote: * Eric Blake wrote on Wed, Sep 15, 2010 at 04:15:13PM CEST: On 09/15/2010 04:37 AM, langdead wrote: Whether does ACLOCAL_AMFLAGS= -I @path only work for Makefile.am? In the context of autoreconf (the only part of the equation belonging to autoconf), we merely call aclocal without grepping for ACLOCAL_AMFLAGS, That's not true. autoreconf.in:autoreconf_current_directory greps for /^ACLOCAL_[A-Z_]*FLAGS\s*=\s*(.*)/ Ah - I missed the regex (I was searching for a literal ACLOCAL_AMFLAGS, and didn't realize that it would be hidden behind a regex). Thanks for correcting me. so it really only works with autoreconf to put literal stuff in that line. When aclocal is run from make, as triggered by the automake-generated rule, $(ACLOCAL_AMFLAGS) undergoes usual make expansion of course. At any rate, it seems like maintaining ACLOCAL_AMFLAGS in Makefile.am is redundant - how hard is it to teach automake to have aclocal _automatically_ include directories mentioned inside AC_CONFIG_MACRO_DIR, to avoid the dual file maintenance headache? If you do this, where will you specify the `--install` flag to aclocal? Still in ACLOCAL_AMFLAGS? -- Jack
Re: aclocal directory not found error
On Thu, Jul 29, 2010 at 4:26 PM, Mike Frysinger vap...@gentoo.org wrote: one example where ive hit this is with projects using git: - initial clone is done - local libtool is configured with AC_CONFIG_MACRO_DIR(m4) like it suggests - m4/ only contains generated files, and those arent in git, and git doesnt keep track of empty dirs. so no m4/ exists at this point in time - Makefile.am has ACLOCAL_FLAGS = -I m4 as it should - initial `autoreconf` aborts due to m4/ not existing because libtoolize wasnt run early enough to populate m4/ with files so i could do `mkdir m4` before the `autoreconf` and forget about it, but the issue comes right back as soon as i do something like `git clean -x -d` (which i frequently do). I also hit this snag with reasonable frequency. I usually `git add` a file m4/.keep, since anything that actually winds up in m4/ is usually put there by aclocal --install. -- Jack
Re: Feature request: per-file compilation flags
On Wed, Mar 31, 2010 at 9:04 AM, Manoj Rajagopalan rma...@umich.edu wrote: A typical use case for me is when one particular function that resides in a file by itself must be compiled without optimizations so that some machine-specific numerical information can be calculated accurately. With C++ the volatile keyword pre-empts this requirement but C and FORTRAN lack this capability. So far my option is to create a convenience library for each file that requires special compilation flags. C also has volatile, with (I thought?) the same semantics: don't optimise access. Here's a way to do this in current automake, compiling foo.c into bar and into baz, but with different flags: bin_PROGRAMS = bar baz ... bar_LDADD = libfoo_bar.a baz_LDADD = libfoo_baz.a noinst_LIBRARIES = libfoo_bar.a libfoo_baz.a libfoo_bar_a_SOURCES = foo.c libfoo_baz_a_SOURCES = foo.c libfoo_bar_a_CFLAGS = -O3 libfoo_baz_a_CFLAGS = -O0 You'll also need AM_PROG_CC_C_O in configure.ac. -- Jack
Re: convenience library dependencies (was: 1.11 doesn't add sources with nonstandard suffixes when making a binary)
2009/12/2 Юрий Пухальский aikip...@gmail.com: Aye, that was what i thought. Jack misled me:) Sorry. I must've got mixed up and thought you were building _PROGRAMS and not _LIBRARIES. I've used noinst_LIBRARIES before when building a program. -- Jack
Re: 1.11 doesn't add sources with nonstandard suffixes when making a binary
2009/11/27 Юрий Пухальский aikip...@gmail.com: Automake links binaries through libtool too, at least in my case. -make output--- /oracle/10.2.0.4/bin/proc CODE=ANSI_C include=../../include include=/oracle/10.2.0.4/lib include=/usr/include ireclen=4800 oreclen=4800 select_error=no release_cursor=no hold_cursor=yes lines=yes ltype=none cpp_suffix=c USERID=xxx/x...@xxx SQLCHECK=SEMANTICS iname=./blabla.pc oname=./blabla.c ProC blabla skipped cc -DHAVE_CONFIG_H -I. -I../../include -g -DLINUX -Wall -W -MT blabla.o -MD -MP -MF .deps/blabla.Tpo -c -o blabla.o blabla.c mv -f .deps/blabla.Tpo .deps/blabla.Po /bin/sh ../../libtool --tag=CC --mode=link cc -g -DLINUX -Wall -W -L/oracle/10.2.0.4/lib -o blabla blabla.o ../../lib/common/libcommon.la ../../lib/pro_c/libproc.la -lclntsh Because here ^ it needed to link against a libtool library. Did you put ../../lib/common/libcommon.la in blabla_LDADD? (Also, if these are convenience libraries only, you can use noinst_ARCHIVES instead and save yourself from compiling everything twice.) -lcurl -lssl -lxml2 -lEx25 -lEec -lpthread -lm libtool: link: cc -g -DLINUX -Wall -W -o blabla blabla.o -L/oracle/10.2.0.4/lib ../../lib/common/.libs/libcommon.a ../../lib/pro_c/.libs/libproc.a -lclntsh -lcurl -lssl -lxml2 -lEx25 -lEec -lpthread -lm -end of make output--- And yes, it works when i make a rule from .pc to .c, but: How do i clean the intermediate .c file in this case? I must add BUILT_SOURCES everywhere, use EXTRA_DIST for distributing the original files. Generally it's less clear than specifying .pc file directly in _SOURCES. You still specify the .pc file in _SOURCES, but let make work out how to make the .c file. I made a simple test: bin_PROGRAMS = foo foo_SOURCES = bar.xyz SUFFIXES = .xyz .xyz.c: cp $ $@ Here is the make output: -- $ make cp bar.xyz bar.c gcc -DPACKAGE_NAME=\FULL-PACKAGE-NAME\ -DPACKAGE_TARNAME=\full-package-name\ -DPACKAGE_VERSION=\VERSION\ -DPACKAGE_STRING=\FULL-PACKAGE-NAME\ VERSION\ -DPACKAGE_BUGREPORT=\BUG-REPORT-ADDRESS\ -DPACKAGE=\full-package-name\ -DVERSION=\VERSION\ -I. -g -O2 -MT bar.o -MD -MP -MF .deps/bar.Tpo -c -o bar.o bar.c mv -f .deps/bar.Tpo .deps/bar.Po gcc -g -O2 -o foo bar.o rm bar.c - Behold: Make (GNU Make 3.81 here) is smart enough to see that bar.c is a temporary file and remove it when finished. As for silliness, it's exactly as silly as default .l.o implicit rule in standard make: .l.o: $(LEX) $(LFLAGS) $ $(CC) $(CFLAGS) -c lex.yy.c rm -f lex.yy.c mv lex.yy.o $@ Just because two people do silly things doesn't make it less silly. -- Jack
Re: 1.11 doesn't add sources with nonstandard suffixes when making a binary
2009/11/28 Юрий Пухальский aikip...@gmail.com: On Fri, Nov 27, 2009 at 4:07 PM, Jack Kelly endgame@gmail.com wrote: 2009/11/27 Юрий Пухальский aikip...@gmail.com: Automake links binaries through libtool too, at least in my case. -make output--- /oracle/10.2.0.4/bin/proc CODE=ANSI_C include=../../include include=/oracle/10.2.0.4/lib include=/usr/include ireclen=4800 oreclen=4800 select_error=no release_cursor=no hold_cursor=yes lines=yes ltype=none cpp_suffix=c USERID=xxx/x...@xxx SQLCHECK=SEMANTICS iname=./blabla.pc oname=./blabla.c ProC blabla skipped cc -DHAVE_CONFIG_H -I. -I../../include -g -DLINUX -Wall -W -MT blabla.o -MD -MP -MF .deps/blabla.Tpo -c -o blabla.o blabla.c mv -f .deps/blabla.Tpo .deps/blabla.Po /bin/sh ../../libtool --tag=CC --mode=link cc -g -DLINUX -Wall -W -L/oracle/10.2.0.4/lib -o blabla blabla.o ../../lib/common/libcommon.la ../../lib/pro_c/libproc.la -lclntsh Because here ^ it needed to link against a libtool library. Did you put ../../lib/common/libcommon.la in blabla_LDADD? Ah, true. Yes, it was in LDADD of course. (Also, if these are convenience libraries only, you can use noinst_ARCHIVES instead and save yourself from compiling everything twice.) Why compile everything twice? Because libtool usually compiles things twice when turning a .foo into a .lo: once for static libraries and once for shared libraries. Automake cannot tell where a libtool convenience library is going to be used and must build the objects for a shared library in case that is what's used, even if not. And i don't see any such thing (_ARCHIVES) in the manual... My bad. I meant noinst_LIBRARIES, so you make a libcommon.a instead of libcommon.la. This goes into LDADD as with libtool convenience libraries. And yes, it works when i make a rule from .pc to .c, but: How do i clean the intermediate .c file in this case? I must add BUILT_SOURCES everywhere, use EXTRA_DIST for distributing the original files. Generally it's less clear than specifying .pc file directly in _SOURCES. You still specify the .pc file in _SOURCES, but let make work out how to make the .c file. Yes, the only thing remains how to clean up the intermediate file. gcc3.81 is fine (btw, doesn't clean up in my case, don't know why!), but we have a whole lot of unices some with their native makes, i have no time to delve into the standard, but i bet they're not required to be that smart, no? I assume you mean make3.81 here. I made a simple test: -snip- See above, mine 3.81 is not smart:) Maybe because is use LDADD with .la. According to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=4073 , all it takes for a file not to be considered intermediate is for it to have an explicit mention anywhere. Does your Makefile.am mention foo.c anywhere? That said, I could find no mention of cleaning up intermediates in http://www.opengroup.org/onlinepubs/9699919799/ , so perhaps it's nonstandard. The behaviour described in the Debian bug also shows how deleting intermediate files can be inefficient. I'm not sure if you're going to run into that behaviour or not, which is not a bug in make. As for silliness, it's exactly as silly as default .l.o implicit rule in standard make: .l.o: $(LEX) $(LFLAGS) $ $(CC) $(CFLAGS) -c lex.yy.c rm -f lex.yy.c mv lex.yy.o $@ Just because two people do silly things doesn't make it less silly. Well, at least here's an explicit removal of an intermediate file. I cannot see how to achieve this in your approach, let alone the IQ of gmake:) It seems like you just have to not mention the file explicitly as a target or prerequisite. If you really want to remove intermediate files, and you want this to work on most makes, it looks like you need to do a suffix rule. Here is my suggestion: .pc.$(OBJEXT): $(PCC) $(PCCFLAGS) iname=$(srcdir)/$*.pc oname=$(builddir)/$*.c $(COMPILE) -c $*.c rm $*.c See http://www.gnu.org/software/hello/manual/automake/Program-Variables.html#index-COMPILE-508 for an explanation of $(COMPILE). The problem with this approach is that you won't be running the same compile command as you will for your standard C files, because the configure script selects one from several different options based on what sort of dependency tracking was chosen. So if it depends on a header or something and that header changes, it won't know to remake foo.o from foo.c. Also, if make gets interrupted after the call to $(PCC) but before the call to $(COMPILE), you'll have the .c file hanging around, anyway. I think my favoured approach would be to use a .pc.c rule. You'll get correct dependency tracking and you can do cleanup by putting foo.c in CLEANFILES. Hope I'm helping. -- Jack
Re: 1.11 doesn't add sources with nonstandard suffixes when making a binary
2009/11/28 Юрий Пухальский aikip...@gmail.com: -snip- My bad. I meant noinst_LIBRARIES, so you make a libcommon.a instead of libcommon.la. This goes into LDADD as with libtool convenience libraries. I haven't checked it, but does it support library dependencies like .la? This i use extensively. Yes, you can. See http://www.gnu.org/software/hello/manual/automake/A-Library.html#A-Library -- Jack
Re: AM_SILENT_RULES doesn't silence texinfo rules
On Wed, Sep 23, 2009 at 2:02 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote:
Uh, oh, more bikeshed color questions. Let's try to find answers that
follow some principle ... ;-)
-snip-
What if you just give up the alignment of the target for tags longer
than 6 characters? Too ugly shed color? Or we go to 8, that might
still be tolerable, maybe let's see an example build.
Sure. I added silent rules to my libfake437 Makefile.am and built it:
$ make all ps pdf html dvi
make all-am
make[1]: Entering directory `/home/endgame/code/libfake437'
GEN doc/fake437-primitive.texi
GEN doc/fake437-surface.texi
GEN doc/fake437-types.texi
MAKEINFO doc/libfake437.info
CC src/libfake437/chars.lo
CC src/libfake437/primitive.lo
CC src/libfake437/surface.lo
CCLD src/libfake437/libfake437.la
CXX src/libfake437++/surface.lo
CXXLDsrc/libfake437++/libfake437++.la
make[1]: Leaving directory `/home/endgame/code/libfake437'
TEXI2DVI doc/libfake437.dvi
DVIPSdoc/libfake437.ps
TEXI2PDF doc/libfake437.pdf
INFOHTML doc/libfake437.html
make: Nothing to be done for `dvi'.
If I drop it back to 6, it looks like this:
$ make all ps pdf html dvi
make all-am
make[1]: Entering directory `/home/endgame/code/libfake437'
GENdoc/fake437-primitive.texi
GENdoc/fake437-surface.texi
GENdoc/fake437-types.texi
MAKEINFO doc/libfake437.info
CC src/libfake437/chars.lo
CC src/libfake437/primitive.lo
CC src/libfake437/surface.lo
CCLD src/libfake437/libfake437.la
CXXsrc/libfake437++/surface.lo
CXXLD src/libfake437++/libfake437++.la
make[1]: Leaving directory `/home/endgame/code/libfake437'
TEXI2DVI doc/libfake437.dvi
DVIPS doc/libfake437.ps
TEXI2PDF doc/libfake437.pdf
INFOHTML doc/libfake437.html
make: Nothing to be done for `dvi'.
I personally prefer it with 8, but I'd rather get something I don't
like committed over a long bikeshed argument.
Revised patch attached. If you're happy with it, I'll cook up some
tests and we can try to get this committed soonish.
From 6ba77498485395acc5b3eb91ef346244dc29b03b Mon Sep 17 00:00:00 2001
From: Jack Kelly endgame@gmail.com
Date: Tue, 22 Sep 2009 12:24:04 +1000
Subject: [PATCH] Add silent rules support for texinfo outputs.
* automake.in (define_verbose_texinfo): Define several new verbose
tagvars and verbose vars.
* automake.in (define_verbose_tagvar): Increase spacing to 8 to
accommodate INFOHTML, MAKEINFO, TEXI2DVI, TEXI2PDF.
* automake.in (handle_texinfo): Additional substitution for
silencing dvips.
* automake.in (output_texinfo_build_rules): Additional
substitutions for silencing texi2dvi and texi2pdf.
* lib/am/texibuild.am: Add silencing to makeinfo, makeinfo --html,
texi2dvi and texi2pdf rules.
* lib/am/texinfos.am: Add silencing to .dvi.ps rule.
---
NEWS|4
automake.in | 22 --
lib/am/texibuild.am | 26 +-
lib/am/texinfos.am |5 +++--
4 files changed, 44 insertions(+), 13 deletions(-)
diff --git a/NEWS b/NEWS
index 7e14ed8..26a8b31 100644
--- a/NEWS
+++ b/NEWS
@@ -1,5 +1,9 @@
New in 1.11a:
+* Changes to automake:
+
+ - automake now generates silenced rules for texinfo outputs.
+
Bugs fixed in 1.11a:
* Bugs introduced by 1.11:
diff --git a/automake.in b/automake.in
index bab8c42..936cced 100755
--- a/automake.in
+++ b/automake.in
@@ -1199,11 +1199,25 @@ sub define_verbose_tagvar ($)
my ($name) = @_;
if (option 'silent-rules')
{
- define_verbose_var ($name, '@echo '. $name . ' ' x (6 - length ($name)) . ' $@;');
+ define_verbose_var ($name, '@echo '. $name . ' ' x (8 - length ($name)) . ' $@;');
define_verbose_var ('at', '@');
}
}
+# define_verbose_texinfo
+# --
+# Engage the needed `silent-rules' machinery for assorted texinfo commands.
+sub define_verbose_texinfo ()
+{
+ my @tagvars = ('DVIPS', 'MAKEINFO', 'INFOHTML', 'TEXI2DVI', 'TEXI2PDF');
+ foreach my $tag (@tagvars)
+{
+ define_verbose_tagvar($tag);
+}
+ define_verbose_var('texinfo', '-q');
+ define_verbose_var('texidevnull', ' /dev/null');
+}
+
# define_verbose_libtool
# --
# Engage the needed `silent-rules' machinery for `libtool --silent'.
@@ -3248,6 +3262,8 @@ sub output_texinfo_build_rules ($$$@)
? '$' : $source),
SOURCE_REAL = $source,
SOURCE_SUFFIX= $ssfx,
+ TEXIQUIET= verbose_flag('texinfo'),
+ TEXIDEVNULL = verbose_flag('texidevnull'),
);
return ($dirstamp, $dpfx.dvi, $dpfx.pdf, $dpfx.ps, $dpfx.html);
}
@@ -3551,6 +3567,7 @@ sub handle_texinfo ()
reject_var 'TEXINFOS', `TEXINFOS' is an anachronism; use `info_TEXINFOS';
# FIXME: I think this is an obsolete future feature name.
reject_var 'html_TEXINFOS', HTML generation not yet supported;
+ define_verbose_texinfo
Re: AM_SILENT_RULES doesn't silence texinfo rules
Hi Ralf, Thanks for the review. I agree with most of your remarks. On Wed, Sep 23, 2009 at 6:42 AM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: * Jack Kelly wrote on Tue, Sep 22, 2009 at 04:33:27AM CEST: + tagvars and verbose vars. + * automake.in (define_verbose_tagvar): increase spacing to 12 to + accommodate MAKEINFOHTML. Ugh, that's very ugly, because it will make it very difficult to align the target name with the abbreviation used for the command, when the build is rushing by. I found 6 to be close to the maximum tolerable length. Can we either agree to create unaligned output, or abbreviate MAKEINFOHTML somehow? Can we go to 8? If we have 8, I can change this to `INFOHTML' and it means `MAKEINFO' is still OK. Currently, the $(AM_V_FOO) output is left-aligned. What if we make it right-aligned with 2 spaces between the end of the tag and $...@? The only argument I can see against this is that things like CC and CCLD won't line up any more. Perhaps we could right-align only things that end in LD or are very long, and add an extra 2 spaces otherwise? Another alternative is to add an arg to define_verbose_tagvar to add 2 spaces of padding because there's a linker to worry about as well. I'm interested in your thoughts. I could do this as a separate patch and then finish the texinfo patch later. -- Jack
Re: AM_SILENT_RULES doesn't silence texinfo rules
On Wed, Sep 23, 2009 at 8:37 AM, Jack Kelly endgame@gmail.com wrote: Hi Ralf, Thanks for the review. I agree with most of your remarks. On Wed, Sep 23, 2009 at 6:42 AM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: * Jack Kelly wrote on Tue, Sep 22, 2009 at 04:33:27AM CEST: + tagvars and verbose vars. + * automake.in (define_verbose_tagvar): increase spacing to 12 to + accommodate MAKEINFOHTML. Ugh, that's very ugly, because it will make it very difficult to align the target name with the abbreviation used for the command, when the build is rushing by. I found 6 to be close to the maximum tolerable length. Can we either agree to create unaligned output, or abbreviate MAKEINFOHTML somehow? Can we go to 8? If we have 8, I can change this to `INFOHTML' and it means `MAKEINFO' is still OK. Another thought: There's currently 2 spaces of padding that are unconditionally output. If we cut those when the tag is more than 6 characters long, the output would look like: MAKEINFO foo.info CC bar.o CCLD bar which would look OK but keep the 6 character limit on tags. What are your thoughts? -- Jack
Re: Feature Request: Improved cross-directory builds (intermediate files)
On Tue, Sep 15, 2009 at 1:33 AM, Bollinger, John C john.bollin...@stjude.org wrote: That would also help in the case where one or more $(DEPDIR)s is accidentally or cluelessly deleted -- the developer would not have to re-run configure (not an obvious solution) to fix the project directory. Do you have to re-run `configure', or was re-running `config.status' enough? It would save a lot of time on checks if you only needed to run `config.status'. -- Jack
Re: compile wrapper script with C++ file
On Fri, Sep 4, 2009 at 10:27 PM, Eric Blakee...@byu.net wrote: I'm not sure whether this is something I'm doing wrong or something wrong with automake, autoconf or libtool. At the moment I'm leaning to autoconf + automake. compile is maintained by automake, so I've redirected your patch there. FWIW, it looks okay to me, but Ralf will have to chime in. I get a step closer but I needed to modify the compile script as well (see below). With both of these changes, everything (C and C++) compile fine and the objects go where they're supposed to. Is the kind of thing that could make its way upstream (maybe even for .cpp file support as well)? I'm not sure how to modify autoconf/configure to do what I did manually...or even if's the right thing. -snip patch- I have no context on this email, but it makes me wonder: - Are C++ compilers that don't understand -c -o common? Does this warrant AM_PROG_CXX_C_O or similar? - I think the standard extensions are .c++, .cc, .cpp and .cxx, going by what http://sources.redhat.com/automake/automake.html#Yacc-and-Lex recognises as `c++-like' extensions for grammar files. But I'm just the peanut gallery. Ralf is the one who needs to weigh in on this. -- Jack
Re: AM_SILENT_RULES doesn't silence texinfo rules
On Sun, Aug 16, 2009 at 9:12 AM, Ralf Wildenhuesralf.wildenh...@gmx.de wrote: Hello Jack, * Jack Kelly wrote on Sun, Aug 16, 2009 at 12:44:57AM CEST: I was hoping that AM_SILENT_RULES would silence the complex makeinfo invocations on texinfo files, but it doesn't. I thought that might've been OK, since the info files are usually generated before distribution, but `make pdf' (or ps, or dvi, or html) still have unsilenced output. I suppose we'll silence more rules in a future release. If you are willing to work on patches (and don't have a problem with copyright assignment) then you are welcome to help. Otherwise it will get done eventually. :-) My assignment is currently incomplete (my main assignment is done, but I'm missing one disclaimer). I'll expect to have the disclaimer done in the next couple of weeks. I've added this to my TODO list. -- Jack
texi2dvi ignores -o under unclear circumstances.
Hello, I think I have found a bug with texi2dvi. It seems to manifest only when using -o to write the dvi to a subdirectory and when the .texi file has a sectioning command like @top. texi2dvi emits an identical copy of the dvi file in the current working directory. I found a similar-sounding report from 2007: http://www.mail-archive.com/bug-texi...@gnu.org/msg03174.html (indeed, I found the problem in the same way: my `make distcheck ' failed because of extra .dvi files left about.) Minimal example to reproduce this bug: doc/foo.texi 8--- \input texinfo @c -*- texinfo -*- @c %**start of header @setfilename foo.info @settitle foo @c %**end of header @node Top @top Top @bye ---8 Running texi2dvi -o doc/foo.dvi doc/foo.texi causes a copy of foo.dvi to be left in the current directory. If you want a minimal autotools example add: configure.ac: 8--- AC_INIT([ambug],[0],[/dev/null]) AM_INIT_AUTOMAKE([foreign]) AC_CONFIG_FILES([Makefile]) AC_OUTPUT ---8 Makefile.am: 8--- info_TEXINFOS = doc/foo.texi ---8 Run `autoreconf -i', then `make distcheck' and it will fail. Is there any other useful information I can provide? -- Jack
Re: texi2dvi ignores -o under unclear circumstances.
On Wed, Aug 12, 2009 at 4:29 AM, Karl Berryk...@freefriends.org wrote: Thanks for the report. Running texi2dvi -o doc/foo.dvi doc/foo.texi causes a copy of foo.dvi I wound up fixing this in my case by adding foo.dvi (equivalent) to CLEANFILES in Makefile.am. Perhaps automake can change the generated rules for `make clean' as an interim fix? There'd have to be some checking that texi2dvi won't clobber files in the working directory. Alternative: Is it feasible (i.e., portable and otherwise safe) to change the generated rules for .dvi files. Perhaps phrase this as: doc/foo.dvi: doc/foo.texi cd doc texi2dvi -o foo.dvi foo.texi instead of doc/foo.dvi: doc/foo.texi texi2dvi -o $@ $ (I'm simplifying here, but hopefully the idea is clear.) When generating Makefile.in? -- Jack
Nonrecursive Makefile.am: Ensuring directory creation?
Hello list, I am writing a nonrecursive Makefile.am, and cannot find the recommended way of requiring that directories in the source tree have had their equivalents created in the build tree. This has led me to write rules like this: 8--- doc/fake437-primitive.texi: doc/$(am__dirstamp) include/fake437/primitive.h; $(EXTRACT_TEXI) ---8 but I feel that using anything starting with $(am__) is asking for trouble by relying on internal details. There's no mention of dirstamp in the info file and Googling didn't yield anything useful either. Does anyone have suggestions of where to look or better approaches? -- Jack
Re: AM_PROG_GCJ fails at `make' if nothing else defines OBJEXT
On Sun, Jun 7, 2009 at 4:06 PM, Ralf Wildenhuesralf.wildenh...@gmx.de wrote:
2. The suffix mechanism might not be quite enough for Java projects
with native methods using the C++ interface.
I'm sorry, but I fail to parse this. Even with the example you gave, it
is unclear to me. Can you rephrase this, state the problem setup in
more detail, and which parts are not supported by Automake? Can these
parts easily be worked around by the Makefile.am author?
This is the best I can come up with:
configure.ac:
8---
AC_INIT([a], [b], [c])
AM_INIT_AUTOMAKE([foreign])
AC_PROG_CXX
AM_PROG_GCJ
AC_PATH_PROG([GCJH], [gcjh], [no])
AS_IF([test $GCJH = no], [AC_MSG_ERROR([bad luck.])])
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
8---
Makefile.am:
8---
noinst_PROGRAMS = cnitest
BUILT_SOURCES = CniTest.h
cnitest_SOURCES = CniTest.java CniTest_native.cc
cnitest_LDFLAGS = --main=CniTest
.java.class:
$(GCJ) -C $
# The -cp is to work around a bug in ubuntu's gcjh setting the
# classpath wrong.
.class.h:
$(GCJH) -cp .:/usr/share/java/libgcj.jar $
8---
CniTest.java:
8---
public class CniTest {
public static native void printFromCxx(String message);
public static void main(String[] args) {
printFromCxx(Hi from C++);
}
}
8---
CniTest_native.cc:
8---
#include java/io/PrintStream.h
#include java/lang/System.h
#include CniTest.h
void CniTest::printFromCxx(::java::lang::String * arg) {
java::lang::System::out-println(arg);
}
8---
What files does this generate in general, can we tell in some way,
ideally, without looking at the .java files? (If we'd have to look
at them, then in principle, the Makefile file (or Makefile.in) would
depend upon the .java file, which seems ugly.)
This has the usual problems with compiling java: multiple outputs from
the one input. (see the _JAVA primary.)
In fact: would it be possible to add GCJ support to the _JAVA primary?
I'm not a java expert, but I'm reasonably sure that every .java file
has either a public class or interface, so adding a rule to
Makefile.in of the form:
CniTest.class: classdir.stamp
might work. Generate one such rule for each java file in a _JAVA
primary and add them to .PHONY.
This then simplifies the Makefile.am, so the explicit .java.class rule
can go away and be replaced with a noinst_JAVA = CniTest.java entry.
The .class.h rule can then be moved into a fragment.
An autoconf test would also be needed to find and AC_SUBST a value for
JAVAC and JAVACFLAGS, and use $(GCJ) -C as one of the options.
(AM_PROG_JAVAC?)
Does this make sense?
-- Jack
Re: AM_PROG_GCJ fails at `make' if nothing else defines OBJEXT
On Mon, May 25, 2009 at 8:17 AM, Jack Kelly endgame@gmail.com wrote: On Mon, May 25, 2009 at 12:42 AM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: Hi Jack, * Jack Kelly wrote on Wed, May 13, 2009 at 01:24:40PM CEST: I've found that if nothing else defines OBJEXT, AM_PROG_GCJ won't do it and then make will fail with an error like: make: *** No rule to make target `Test.', needed by `test'. Stop. Thank you for the bug report and example test. I agree that it is a bug, but I think fixing it will require at least some Autoconf support. Maybe we should start thinking of moving AM_PROG_GCJ into the Autoconf language framework. BTW, EXEEXT needs a definition, too. While I think of it: do you need a copyright assignment form from me, or is that only for larger contributions? -- Jack
Re: AM_PROG_GCJ fails at `make' if nothing else defines OBJEXT
On Mon, May 25, 2009 at 12:42 AM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: Hi Jack, * Jack Kelly wrote on Wed, May 13, 2009 at 01:24:40PM CEST: I've found that if nothing else defines OBJEXT, AM_PROG_GCJ won't do it and then make will fail with an error like: make: *** No rule to make target `Test.', needed by `test'. Stop. Thank you for the bug report and example test. I agree that it is a bug, but I think fixing it will require at least some Autoconf support. Maybe we should start thinking of moving AM_PROG_GCJ into the Autoconf language framework. BTW, EXEEXT needs a definition, too. Thanks for doing that, Ralf. I've given up on playing with GCJ for the moment, but here are some other things that I've noticed: 1. AM_PROG_GCJ might want to think about using AC_CHECK_TOOLS instead of AC_CHECK_PROGS - to catch a cross-compiled gcj that's building binaries for a different host. 2. The suffix mechanism might not be quite enough for Java projects with native methods using the C++ interface. For these, it appears that gcj wants something like this (my best guess here, docs are quite sketchy): Suppose Foo.cc contains the implementation of the native methods declared in Foo.java. Then to compile, the following is needed: # Make Foo.class gcj -C Foo.java # Make Foo.h, which is #include'd by Foo.cc gcjh Foo.class g++ -c -o Foo.o Foo.cc gcj -o Foo.class.o Foo.class # Or instead of the above: gcj -c -o Foo.class.o Foo.java Then link to taste, using gcj to call the linker. -- Jack
