> 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
>[...]
> 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 unfor
> 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
>> 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
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.
>> 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.
> Re
>>> 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
>> 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 presen
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
> 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 `
>> 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!
Wern
> 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 \
>> 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
[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 += ttfautohi
> 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
> 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 suffix
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:
m
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 ha
> 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
>> (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 t
[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 mail
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
rep
22 matches
Mail list logo
