Re: armflang: error: unknown argument: '-soname'
> While libtool has a new maintainer (Alex Ameen), essentially > nothing happens, which is quite unfortunate... > > 1) libtool 2.4.7 was released in March 2022 (I don't know if Alex did >it), He did. > 2) When a package appears to be unmaintained, the first thing to do >[...] Thanks for this guide. Hopefully, people who want to have patches added to the libtool git repository will follow this. Werner
Re: armflang: error: unknown argument: '-soname'
> here is a patch for libtool that Francois Coppens and I submitted to > libtool in February. I think we did something went wrong in the PR > process because it has still not been included... [...] While libtool has a new maintainer (Alex Ameen), essentially nothing happens, which is quite unfortunate... Werner
Re: installing documentation one level higher
> An alternative approach would be the following snippet: > > dist_doc_DATA = doc/bar.html > > doc_imgdir = $(docdir)/img > dist_doc_img_DATA = doc/img/baz.png That's it, thanks a lot! Werner
Re: installing documentation one level higher
>> Folks, >> >> >> >> My current rule (in the top-level `Makefile.am`) is >> >>nobase_dist_doc_DATA = doc/bar.html \ >> doc/img/baz.png > > I think you wanna get rid of the 'nobase_' prefix (but haven't > tested). If I do that, all files are installed into the same directory, according to the documentation. This is not what I want; images should still be in the `img` subdirectory. A solution to the problem is the 'install-data-hook' target to move up all documentation files and directories by one level (I haven't tried this yet, though). I just wonder whether there is a better, more 'natural' one. Werner
installing documentation one level higher
Folks, I have the following structure in my source package foo/ |__ doc/ | |__ bar.html | | | |__ img/ | |__ baz.png | |__ Makefile.am My current rule (in the top-level `Makefile.am`) is nobase_dist_doc_DATA = doc/bar.html \ doc/img/baz.png After `make install` the files are installed in /usr/local/share/doc/foo/doc/bar.html /usr/local/share/doc/foo/doc/img/baz.png However, I would like to have them in /usr/local/share/doc/foo/bar.html /usr/local/share/doc/foo/img/baz.png that is, one directory level higher. How can I achieve this? Werner
Re: How to prevent distribution of `texinfo.tex`
>> I vote for removing this file from the list of mandatory files. > > It's not mandatory. It only gets included when the file is present > in your development workspace (presumably by some mistake?) when you > run automake. Hmm. I can no longer repeat the problem. Sorry for the noise. > Removing anything from this list will just break any projects that > depend on the current behaviour when they switch to a new version of > Automake, probably in subtle and hard-to-notice ways. I imagined an option to specify files that are not distributed by default. Werner
Re: How to prevent distribution of `texinfo.tex`
>>> Yeah, it would be nice to have a means to control that. > > Yes it is really not a good solution in this case. The file is > detected at "automake" time and the rule to distribute texinfo.tex > is baked into the generated Makefile.in. That then gets bundled up > into the tarball. Yep. The size of `texinfo.tex` (374kByte) is not significant today, but if there is no Texinfo documentation in a project it is completely pointless to include it. I vote for removing this file from the list of mandatory files. Besides the fact that even a lot of GNU projects lack Texinfo documentation, distributing `texinfo.tex` alone is very US-centric, since the language-specific support files like `txi-de.tex` are not automatically distributed. Werner
Re: How to prevent distribution of `texinfo.tex`
>> The file `texinfo.tex` is in the list of files (given by `automake >> --help`) that gets always distributed. How can I disable this? I >> don't have texinfo documentation. > > The texinfo.tex file (and others listed along with it) is included > in the distribution only if the file is present in your project > workspace when you run "automake" to (re)generate Makefile.in. OK, thanks. > As far as I know there is no way to disable this behaviour, although > I agree the automagic file inclusion can be a bit funky. Yeah, it would be nice to have a means to control that. Werner
How to prevent distribution of `texinfo.tex`
The file `texinfo.tex` is in the list of files (given by `automake --help`) that gets always distributed. How can I disable this? I don't have texinfo documentation. Werner
Re: parallel build issues
> For example, perhaps you have the same "frontend" directory listed > also in SUBDIRS for some other unrelated makefile? That is probably > the simplest way this situation could happen. The problem is as follows. * In the `frontend` directory, the binary `ttfautohintGUI` is built. * In the `doc` directory, I need the `ttfautohintGUI` binary to create a snapshot image of its GUI. To do this, I have something like the following rule: ttfautohintGUI.png: $(top_srcdir)/frontend/maingui.cpp \ $(top_srcdir)/configure.ac \ $(srcdir)/ttfautohintGUI.stylesheet cd $(top_builddir)/frontend \ && $(MAKE) $(AM_MAKEFLAGS) ttfautohintGUI$(EXEEXT) $(SHELL) $(srcdir)/make-snapshot.sh \ $(top_builddir)/frontend/ttfautohintGUI$(EXEEXT) I must admit that I no longer remember why I did it this way. It works fine for non-parallel builds (and I have obviously never tested with make's `-j` option). Now I want to do better :-) However, the problem persists: `ttfautohintGUI` gets built in the `frontend` directory, and there is a dependency on the binary in the `doc` directory. Is there a clean solution for that? Werner
Re: parallel build issues
>> The problem is not related to the snippet you posted. The >> concurrent recursive make invocations are being spawned from >> somewhere else in your build system. Found the problem! I was indeed calling `make` concurrently (within the `doc` directory). Thanks a lot for your help! Werner
Re: parallel build issues
> The problem is not related to the snippet you posted. The > concurrent recursive make invocations are being spawned from > somewhere else in your build system. The `Makefile.am` file one level higher is as follows. ACLOCAL_AMFLAGS = -I gnulib/m4 -I m4 SUBDIRS = gnulib/src \ lib \ frontend \ doc EXTRA_DIST = bootstrap \ bootstrap.conf \ FTL.TXT \ gnulib/m4/gnulib-cache.m4 \ GPLv2.TXT \ README \ TODO \ .version BUILT_SOURCES = .version .version: echo $(VERSION) > $@-t && mv $@-t $@ dist-hook: echo $(VERSION) > $(distdir)/VERSION.TXT Looks pretty standard to me, but maybe I'm wrong. Werner
Re: parallel build issues
>> bin_PROGRAMS += ttfautohintGUI > > Is Automake smart enough to realize what you’ve done there? According to the documentation, `+=` is recognized. > Try listing both output programs on a single bin_PROGRAMS line. Alas, this doesn't work; it aborts with the same error. Werner
parallel build issues
[automake 1.16.3 autoconf 2.71] Folks, I have a `Makefile.am` in a `frontend` subdirectory that looks like the following (abridged). bin_PROGRAMS = ttfautohint ttfautohint_SOURCES = info.cpp \ info.h \ main.cpp bin_PROGRAMS += ttfautohintGUI ttfautohintGUI_SOURCES = ddlineedit.cpp \ ddlineedit.h \ info.cpp \ info.h \ main.cpp \ maingui.cpp \ maingui.h \ ttlineedit.cpp \ ttlineedit.h nodist_ttfautohintGUI_SOURCES = ddlineedit.moc.cpp \ maingui.moc.cpp \ static-plugins.cpp \ ttlineedit.moc.cpp ttfautohintGUI_CXXFLAGS = $(QT_CXXFLAGS) ttfautohintGUI_LDFLAGS = $(QT_LDFLAGS) ttfautohintGUI_CPPFLAGS = $(AM_CPPFLAGS) \ $(QT_CPPFLAGS) \ -DBUILD_GUI ttfautohintGUI_LDADD = $(LDADD) \ $(QT_LIBS) BUILT_SOURCES = ddlineedit.moc.cpp \ maingui.moc.cpp \ static-plugins.cpp \ ttlineedit.moc.cpp Running the generated `Makefile` with `make -j12`, I get this: ... Making all in frontend make[2]: Entering directory '.../frontend' ... make all-am make[3]: Entering directory '.../frontend' CXX info.o CXX main.o CXX ttfautohintGUI-ddlineedit.o CXX ttfautohintGUI-info.o CXX ttfautohintGUI-main.o CXX ttfautohintGUI-maingui.o CXX ttfautohintGUI-ttlineedit.o make ttfautohint CXX ttfautohintGUI-ddlineedit.moc.o CXX ttfautohintGUI-maingui.moc.o CXX ttfautohintGUI-static-plugins.o CXX ttfautohintGUI-ttlineedit.moc.o make[4]: Entering directory '.../frontend' CXX info.o make ttfautohintGUI make[4]: Entering directory '.../frontend' CXXLDttfautohintGUI CXX main.o mv: cannot stat '.deps/info.Tpo': No such file or directory make[4]: *** [Makefile:1401: info.o] Error 1 make[4]: *** Waiting for unfinished jobs CXXLDttfautohint make[4]: Leaving directory '.../frontend' ... What am I doing wrong? I would be glad for any pointers. Werner
Re: GNU Automake 1.15.1 released
> We are pleased to announce the GNU Automake 1.15.1 maintenance > release. Thanks a lot for your efforts! Note that you forgot to tag the new release in the git repository, so please do that :-) Werner
Re: Problems with gnits standard and git-version-gen
> 1.00rc0 > > Personally, when I see a version number like that, I'm never sure > what it means. Probably the first rc leading up to 1.00, but maybe > it is an rc for 1.01 after 1.00. Well, I have *never* encountered that `1.00rc0' means a release candidate for 1.01. Have you? > And suffixes sort badly in long lists (see, e.g., > http://ftp.isc.org/isc/bind9/). Anyway. Not trying to change your > ways, but since you raised the subject, tossing in my gratuitious > opinion, sorry. :-) For `political reasons' I need a `1.00' in the version string. Otherwise, I would be just happy with 0.99.91 or so. > [...] he included "support" in automake for the extra gnits checks > we were thinking about. That is all. Well, some tests are quite useful. It's just the version number checking that I consider... limited. Anyways, the problem with `git-version-gen' are real. There might be good reasons to have, say 2.17-foobar to indicate a special modification of 2.17, and git-version-gen doesn't like it. Werner
Problems with gnits standard and git-version-gen
Folks, I try to make a release candidate. Theoretically, I could use version `0.99.99' or something similar, however, it looks much nicer IMHO to use `1.00rc0'. Unfortunately, the gnits standard currently prevents this. To be more precise, it's the following regex in the automake script: my $GNITS_VERSION_PATTERN = '\d+\.\d+([a-z]|\.\d+)?(-[A-Za-z0-9]+)?'; My next try was using `1.00-rc0'. However, now git-version-get complains since this line vtag=`echo "$v" | sed 's/-.*//'` strips off any `-' characters while parsing output from `git describe'. IMHO, git-version-gen's approach is too simplistic and must be improved. On the other hand, I wonder why the gnits standard doesn't allow non-numeric suffixes... Werner
generated files issues
Folks, I have two templates, `foo.cin' and `foo.hin', which are used to create the files `foo.c' and `foo.h', respectively. File `foo.h' get's included in another header file, `bar.h', which in turn is included by almost every other file of library `foobar' (including `foo.c'). Currently, I have this in my Makefile.am: libfoobar_la_SOURCES = \ bar.h \ ... \ foo.c \ foo.h \ ... foo.h: foo.hin do-something < foo.hin > foo.h foo.c: foo.cin do-something < foo.cin > foo.c Unfortunately, this doesn't work. While calling `make', I get GEN foo.c CC foo.lo In file included from foo.c: bar.h: fatal error: foo.h: No such file or directory compilation terminated. make[2]: *** [foo.lo] Error 1 What's the recommended solution to such a problem, except adding dependencies for all .c files which directly or indirectly include `foo.h' (which is both inconvenient and error prone)? Werner
Re: aclocal and AC_CONFIG_MACRO_DIR
> AC_CONFIG_MACRO_DIRS is the one you want to use (plural form). Thanks. I wasn't aware that it exists (since it is missing in the autoconf 2.69 documentation). I now see that it is mentioned in automake, but the macro's prefix `AC_' didn't make me look it up there. Werner
Re: generated documentation
>> (1) If the user unpacks the tarball, the rules are not executed. >> (2) If the user does a bootstrap from the repository to do `make >> dist', they are needed. >> (3) If the user changes a doc source file in the tarball and wants >> to regenerate the documentation, the rules are needed too. > ... >> (b) If the tests for pandoc and pdftex fail, disable the build >> rules or provide no-ops. This is OK for (1) and (3), but not >> satisfactory for (2). > > Why is (b) unsatisfactory for (2)? > > I'm presuming that when pandoc/pdftex are not found, not only are > the standard makefile rules using them disabled, but alternative > rules enabled which just say something like: > > if have_pandoc > foo.html: foo.tex > $(PANDOC) balah blah blah > else > foo.html: foo.tex > echo 1>&2 " OMGOMG can't generate $@" > echo 1>&2 " please install pandoc and reconfigure" > endif Thanks for your response! I was a bit unclear. Your solution happens at `make' time, which is OK, and I will do what you suggest. However, my question was primarily related to the configure script, and I think I've found the solution: If `configure' doesn't find the documentation files, checks for pandoc and pdftex result in fatal errors if they aren't available, otherwise they cause warnings only. Werner
generated documentation
[Not sure whether my previous attempt in sending this email was successful since I've just subscribed to the list, and I can't see it in the archive, so I'm retrying. Sorry for any double posts.] Folks, it's not clear to me whether I shall post this question in the automake or autoconf mailing list, but since I use the automake framework, I start here :-) In my package, I have generated documentation files: foo.html and foo.pdf. In the tarball I want to distribute them. In the git repository they are not present, and rules in the Makefile generate them. Now my question: I need pandoc and pdftex for building the docs. What's the best way to test for them in the configure script? Note that I have already an option --without-doc to completely disable a doc build, so this is not a problem here. (1) If the user unpacks the tarball, the rules are not executed. (2) If the user does a bootstrap from the repository to do `make dist', they are needed. (3) If the user changes a doc source file in the tarball and wants to regenerate the documentation, the rules are needed too. The possible solutions for configure.ac I've found so far are as follows. (a) Test for pandoc and pdftex only if foo.html and foo.pdf are not present. Abort if one of them is missing. This works fine for (1) and (2), but fails for (3). (b) If the tests for pandoc and pdftex fail, disable the build rules or provide no-ops. This is OK for (1) and (3), but not satisfactory for (2). Any other ideas? Is there a `standard' way to handle this problem? Werner
generated documentation
Folks, it's not clear to me whether I shall post this question in the automake or autoconf mailing list, but since I use the automake framework, I start here :-) In my package, I have generated documentation files: foo.html and foo.pdf. In the tarball I want to distribute them. In the git repository they are not present, and rules in the Makefile generate them. Now my question: I need pandoc and pdftex for building the docs. What's the best way to test for them in the configure script? Note that I have already an option --without-doc to completely disable a doc build, so this is not a problem here. (1) If the user unpacks the tarball, the rules are not executed. (2) If the user does a bootstrap from the repository to do `make dist', they are needed. (3) If the user changes a doc source file in the tarball and wants to regenerate the documentation, the rules are needed too. The possible solutions for configure.ac I've found so far are as follows. (a) Test for pandoc and pdftex only if foo.html and foo.pdf are not present. Abort if one of them is missing. This works fine for (1) and (2), but fails for (3). (b) If the tests for pandoc and pdftex fail, disable the build rules or provide no-ops. This is OK for (1) and (3), but not satisfactory for (2). Any other ideas? Is there a `standard' way to handle this problem? Werner
