*CLEANFILES dependency
Hello, This is my first message on this list. I'm doing a lot of autotools related work recently so (depending on my level of success) it may be the first of many :-) I read in the Automake manual (the one at www.gnu.org) about CLEANFILES, DISTCLEANFILES and so on. One thing I noticed after going over the manuals and searching the web is that nothing says any of them depend on the others. For example, if I add a file to DISTCLEANFILES, so I also need to manually add it to CLEANFILES? Does the former include the $(latter)? It seems the answer is yes, judging by some code I've seen, but 1) It's just my guess, 2) It should probably be documented and made clear in the Automake manual Since it would be just a minor edit to the texinfo files, I suppose I could send a patch - but first I need to know the answer to my question, of course. I'm going to write some dummy Makefile.am and see what happens in the final Makefile, but I still do prefer to know whether such inclusion of *CLEANFILES is formal and can be expected from Automake. Thanks in advance, fr33domlover PGP key ID: 937A67EF signature.asc Description: PGP signature
make install-dirPRIMARY
Hello, I'm writing a Makefile.am with a custom piece for building, distributing and installing Doxygen-generated documentation. All the generated files are used as values for the special-scheme variables, e.g. 'dist_reference_DATA = index.html'. Installation targets are automatically generated, but aren't very pretty. For example, 'dist_reference_DATA' generates target 'install-referenceDATA'. This is relatively readable, but when the destination directory part gets longer, e.g. reference_full_html, it becomes somewhat less pretty, certainly less than the elegant 'install-info', 'install-html' and so on. So I had an idea - define my own pretty targets like `install-ref`, `install-ref-html` etc., and make then directly depend on those less pretty targets Automake generates. The question is, is the naming scheme of those generated targets more or less consistent? Is it safe to rely on it to not change often? If not, what other options do I have? I wouldn't want to write manual install targets copied from Makefile, since that would be dangerous duplication. -- fr33 signature.asc Description: PGP signature
Using $(variables) in source file list
Hello automakers! I'm using autoconf 2.69 and automake 1.11.6 (Debian 7 stable). Recently I tried defining the source code folder name using a variable and strange things happen. I'm not sure whether this is a bug or my mistake. Here's the revelant part from Makefile.am, before the change, which *does* work: lib_LTLIBRARIES = libsgp.la libsgp_la_SOURCES = \ src/Command.cpp \ src/CommandStack.cpp Now, the change I made is here below. The result is that .Plo files are created under $(src)/.deps instead of src/.deps, and then the code that uses them fails to find them and `make` failes. src = src lib_LTLIBRARIES = libsgp.la libsgp_la_SOURCES = \ $(src)/Command.cpp \ $(src)/CommandStack.cpp The following change surprisingly causes `make` to succeed, but the .Plo files are still created in the wrong place. I don't mind having a folder named $(src) literally, but it's not the intended behavior. code = src src = $(code) lib_LTLIBRARIES = libsgp.la libsgp_la_SOURCES = \ $(src)/Command.cpp \ $(src)/CommandStack.cpp I also tried using src := src but the result was the same. Why does it happen? Is this a known problem? I didn't find any material on the web. Of course I can move the definition of src to configure.ac, but I'd like to know what I'm missing (or is it a bug). If you use OpenNIC, the code can be browsed (and cloned of course) at http://git.partager.null/sgp-dox.git. -- fr33 signature.asc Description: PGP signature
Re: *CLEANFILES dependency
On 2014-08-12 Nick Bowler nbow...@elliptictech.com wrote: Yes, but I think you have clean/distclean backwards. There are four clean targets: mostlyclean clean distclean maintainer-clean Each target in the list performs all the actions of the targets above it in addition to its own actions. So if you add something to DISTCLEANFILES, it will be removed by both distclean and maintainer-clean, but not removed by mostlyclean or clean. As you have observed, this does not appear to be explicitly documented in the manual. So typically, a generated file would be added to exactly one of the *CLEANFILES variables. Thank you! :-) -- fr33 signature.asc Description: PGP signature
Re: make install-dirPRIMARY
On 2014-08-12 fr33domlover fr33domlo...@riseup.net wrote: Hello, I'm writing a Makefile.am with a custom piece for building, distributing and installing Doxygen-generated documentation. All the generated files are used as values for the special-scheme variables, e.g. 'dist_reference_DATA = index.html'. Installation targets are automatically generated, but aren't very pretty. For example, 'dist_reference_DATA' generates target 'install-referenceDATA'. This is relatively readable, but when the destination directory part gets longer, e.g. reference_full_html, it becomes somewhat less pretty, certainly less than the elegant 'install-info', 'install-html' and so on. So I had an idea - define my own pretty targets like `install-ref`, `install-ref-html` etc., and make then directly depend on those less pretty targets Automake generates. The question is, is the naming scheme of those generated targets more or less consistent? Is it safe to rely on it to not change often? If not, what other options do I have? I wouldn't want to write manual install targets copied from Makefile, since that would be dangerous duplication. -- fr33 Anyone has some advice? My code uses those targets at the moment, but I'm not sure it's good for long term. signature.asc Description: PGP signature
nodist_noinst_SCRIPTS and `make distcheck`
Hello, I'm using automake 1.11.6 (from debian 7 stable). I have a script in my project, which creates the ChangeLog from the git log (it's the script from gnulib). Since the script is meant only for `make dist`, it's neither distributed nor installed. I didn't put it in any variable, not even nodist_noinst_SCRIPTS. Everything seemed to work, including `make dist`. Now I tried `make distcheck` for the first time. It fails because it cannot find the script. When it copies the srcdir content into a new temporary place, it simply forgets to take the script, maybe because there are no targets for it at all. So the result is an error, file not found. I tried making the ChangeLog target depend on that script and/or define nodist_noinst_SCRIPTS, but then the result is another error: all-am requires util/git2cl.pl, but there are no rules for building it. Of course I can add a fake rule for the script, which does nothing, but is that a good solution or a dirty workaround? Q: Why don't I just distribute the script? A: It's meant only for maintainers and requires the full git history, so it's useless in a tarball. What should I do? I do want my `make distcheck` to succeed, and this issue seems to be the only thing preventing that. Thanks! fr33domlover PGP key ID: 937A67EF signature.asc Description: PGP signature
Re: nodist_noinst_SCRIPTS and `make distcheck`
Hello Nick, On 2014-10-20 Nick Bowler nbow...@elliptictech.com wrote: There are two related things that distcheck is testing here, and either one of them may be tripping you up. First, distcheck is checking that users can run make dist from your tarball. Indeed `make dist` succeeds. Second, distcheck is checking that all this works properly in VPATH builds (i.e., with srcdir != builddir). I didn't try, but I assume it will work because the only problem is that script, which IS present in the right place. The Makefile.am makes sure it will be taken from $srcdir. The problem happens because `make distcheck` copies files from the source repo into a new temporary srcdir. For the first point, in principle it is OK to have ChangeLog generated automatically from your VCS. But you need to be careful that the distributed ChangeLog's prerequisites are present and that it is up-to-date, so that make dist from the tarball does not attempt to re-generate it (since obviously this process will not function). One way to solve this is to sidestep it entirely with a dist-hook, which can test if you are building from VCS, then generate the ChangeLog as appropriate. Something like this (untested): dist-hook: dist-create-changelog dist-create-changelog: if test -d $(srcdir)/.git; then \ : generate $(distdir)/ChangeLog here; \ fi .PHONY: dist-create-changelog Here we rely on the fact that Automake will automagically include ChangeLog in the tarball if it is present in srcdir. You may want to also add a distcheck-hook to ensure that this actually happens. This is exactly what I do :-) And like I said, it does work. For the second point, if you are not routinely testing VPATH builds from your git tree at all, just be aware that distcheck may uncover bugs related to this feature. It's going to be the first release, so I didn't try distcheck until now. The line which generates the ChangeLog in the snippet above requires that script to be present in $srcdir - but distcheck doesn't copy it to its temporary srcdir, so it's not present. The solution to the problem of .git not being present during distcheck may be: In distcheck-hook, take it from the right place (i.e. $(srcdir)/../.git) and then try to make the ChangeLog again. The thing about the script is, that while I can do the same (pick the script from the original $srcdir), it would be somewhat wrong design-wise - if a script is used for `make dist`, then `make distcheck` should copy it into the temporary srcdir just like the source code. While not installed nor distributed, the script is *used* during the process and is therefore required. How do I tell `make distcheck` to do that? I did try to have the ChangeLog target depend on the script file, but then instead of being satisfied by it (since the script file exists), it complains there's no target for it (but none needed since it's a file and it already exists). Is there a solution for this in automake? If not, I'll take a look at the implementation of distcheck and see if anything can be done about it (maybe some kind of variable(s) which means files used for inst/dist/both but are themselves nodist_noinst). fr33domlover PGP key ID: 937A67EF signature.asc Description: PGP signature
Re: nodist_noinst_SCRIPTS and `make distcheck`
On 2014-10-20 Nick Bowler nbow...@elliptictech.com wrote: Not exactly. Distcheck first creates a distribution tarball (i.e., make dist), THEN it unpacks the tarball into a temporary srcdir and tests that. In other words, distcheck is directly testing the 'user experience' when they unpack a tarball you publish. Part of that user experience is that the following sequence should work: - download your package tarball from a website. - unpack it - ./configure make dist Since your script is not distributed, that sequence must not require the script to work. Thanks! Now I understand how distcheck really works. I'll just make the ChangeLog target check if the script and .git are available, as you suggest. Problem solved :-) signature.asc Description: PGP signature
Portable Use of Variables
Hello, I'm a bit confused about all the expressive features and ways to use makefile variables, so just to be sure - http://www.gnu.org/software/make/manual/html_node/Substitution-Refs.html Are these uses of variables portable, or should a portable Makefile.am use only the plain $(var) form without the tricks? I'm adapting the doxygen Makefile.am from gtkmm (GTK+ C++ binding) for my use, but they use text functions and variable features a lot with -no-portability, so I'm trying to make it work with -Wall -Werror. I hope it's worth the effort :-) Just trying to have a clean makefile... -- fr33
Re: Portable Use of Variables
On 2014-10-27 Eric Blake ebl...@redhat.com wrote: On 10/27/2014 11:11 AM, Nick Bowler wrote: On 2014-10-26 22:15 +0200, fr33domlover wrote: I'm a bit confused about all the expressive features and ways to use makefile variables, so just to be sure - http://www.gnu.org/software/make/manual/html_node/Substitution-Refs.html Are these uses of variables portable, or should a portable Makefile.am use only the plain $(var) form without the tricks? The first form of expansion on that page, $(var:.a=.b), should be OK. They are standard in POSIX and work on all make implementations that I know of. The version with % characters is not portable. That said, POSIX is hoping to standardize it in the next few years: http://austingroupbugs.net/view.php?id=519 Hmmm I was sure it's portable because `make distcheck` doesn't complain about the %s, and I'm using -Werror and -Wall automake flags. How bad is it? I suppose it's not specific to just GNU make alone? signature.asc Description: PGP signature
Re: Rarely rebuilt files
On 2014-11-11 Simon Richter simon.rich...@hogyros.de wrote: Hi, On 11.11.2014 18:50, fr33domlover wrote: When I ran `make distcheck`, it failed because the HTML files don't get cleaned by `make distclean`. That makes sense, but specifically for my package this is not an error. If you assume that few people build these files, they should be distributed as well (so you don't need the tools to rebuild them), otherwise you require your users building from source to have the tools anyway, and you gain nothing. When the files are distributed, the distcheck should recognize that these belong in the source package, and not show an error. Simon Hmmm I think I didn't make myself clear. So just to make sure, before I cause confusion: The files are indeed distributed validaly. The problem is that they are not cleaned by `make distclean`. I intentionally made them clean only on `make maintainer-clean`. When `make distcheck` sees they don't get cleaned by `make distclean`, it produces an error. signature.asc Description: PGP signature
Re: Rarely rebuilt files
On 2014-11-11 Simon Richter simon.rich...@hogyros.de wrote: Hi, On 11.11.2014 21:07, fr33domlover wrote: When the files are distributed, the distcheck should recognize that these belong in the source package, and not show an error. Hmmm I think I didn't make myself clear. So just to make sure, before I cause confusion: The files are indeed distributed validaly. The problem is that they are not cleaned by `make distclean`. I intentionally made them clean only on `make maintainer-clean`. When `make distcheck` sees they don't get cleaned by `make distclean`, it produces an error. If they are distributed, the distcheck target should not complain, because it should expect the files to be there. Can you post the relevant parts of the Makefile.am ? Simon The files are not specified in any variable with 'dist_' prefix. They are distributed because I wrote a dist-hook. Normally I would also add them to DISTCLEANFILES, but in this case I decided I prefer MAINTAINERCLEANFILES, which is why `make distclean` doesn't remove them and the error is generated by `make distcheck`. signature.asc Description: PGP signature
Re: Rarely rebuilt files
On 2014-11-12 Nick Bowler nbow...@elliptictech.com wrote: Hello, On 2014-11-11 22:07 +0200, fr33domlover wrote: On 2014-11-11 Simon Richter simon.rich...@hogyros.de wrote: On 11.11.2014 18:50, fr33domlover wrote: When I ran `make distcheck`, it failed because the HTML files don't get cleaned by `make distclean`. That makes sense, but specifically for my package this is not an error. [...] Hmmm I think I didn't make myself clear. So just to make sure, before I cause confusion: The files are indeed distributed validaly. The problem is that they are not cleaned by `make distclean`. I intentionally made them clean only on `make maintainer-clean`. When `make distcheck` sees they don't get cleaned by `make distclean`, it produces an error. I think your distribution tarballs are not working properly in VPATH builds. Distcheck has found the problem but it is maybe not reporting it very well. Here's a simplified view of how distcheck tests make distclean: - It unpacks the distribution tarball to be tested, and marks all unpacked files read-only. - It runs configure in a separate, empty directory, i.e., srcdir != builddir. - After doing a bunch of other tests, it runs make distclean. - Then, if the build directory is not empty, report an error. What is probably happening is that in VPATH builds from your tarball, your documentation is being rebuilt even though it was distributed. This is leaving files behind in your build directory, which distcheck is then complaining about. Hope that helps, Maybe this is a problem too, but there's something before that - see the make distclean part above. I put the HTML files to be removed by make maintainer-clean, which means that make distclean is *not supposed to remove them* - anyway, this is what I intend. So even without the error you suggest, it should complain about files left in the builddir. Am I right? I'll also check to see if the docs get unnecessarily rebuilt. signature.asc Description: PGP signature
Re: Rarely rebuilt files
On 2014-11-12 fr33domlover fr33domlo...@riseup.net wrote: Here's part of my code: all-local: ref ref: ref-html ref-html: ref-full-html ref-api-html ref-full: ref-full-html ref-api: ref-api-html ref-full-html: $(reference_full_devhelp_chosen) \ $(dist_reference_full_DATA) ref-api-html: $(reference_api_devhelp_chosen) \ $(dist_reference_api_DATA) How does make determine whether it should rebuilt? After unpacking, the tag file obviously has new last-modified/created time - maybe this causes make to decide it must rebuild? The file is fresh new from the tarball, but it was of course built at dist-time... For the record in mail archives for future reference - the problem was that the files were in maintainer-clean and not in distclean. This is intentional, and as expected it causes make distcheck to fail. When moving them to DISTCLEANFILES, there are no errors. However, there's an issue with distributed generated docs: There is one copy in scrdir and another one in builddir. So if you want them both to be cleaned, make sure maintainer-clean does it :-) The issue of timestamps Nick mentioned seems to exist too, and it matters when srcdir == builddir. I'm working on it. signature.asc Description: PGP signature
