Why not just write it as:
a_SOURCES = aprog/main.c \
aprog/foo.c \
aprog/bar.c \
aprog/baz.c ...
??
On Mon, Jul 17, 2023 at 12:55:59AM +0200, Jan Engelhardt wrote:
> Given
>
> a_SOURCES = aprog/main.c aprog/foo.c aprog/bar.c aprog/baz.c ...
>
> The more source files there ar
now if anyone is working on that document
> anymore.
>
> > I wonder if recipe to build `distcheck' target
> > as compiled by automake gets same form as John Calcote
> > describes it in chapter 3 his Practitioner's Guide (2nd ed.).
>
> I have not read th
Zack,
These are terms I made up when I wrote the No Starch Press Autotools book -
the manual had no existing name for these concepts, so I just contrived
names for them.
John
On Tue, Feb 2, 2021 at 11:39 AM Zack Weinberg wrote:
> On Tue, Feb 2, 2021 at 1:19 PM DUDZIAK Krzysztof
>
ve. People want to pick up a book or a manual and become
an expert within the first chapter - they have busy lives and don't want to
spend a good portion of it learning esoteric tools by absorbing long
reference manuals. Therefore, if the documentation were to be supplemented
with a good getting-started guide, it would go a long way toward improving
the documentation.
Regards,
John
On Mon, Apr 22, 2019 at 10:12 PM Kip Warner wrote:
> How can I solve this problem?
Try using a stamp file only created on success. To do this you’ll need to
wrap your test calls in a script that creates the stamp file on success.
John
>
but if you need functionality
offered by libtool then why not just use libtool?
John
>
e is assumed to be proper make script and
copied directly to the output file.
I suggest making your ast handle non automake chunks as a specific token
type designed to be passed through without modifications.
Just a few thoughts for you to consider.
Kind regards,
John Calcote
ou might find helpful:
http://www.freesoftwaremagazine.com/books/autotools_a_guide_to_autoconf_automake_libtool
John
On Mon, Sep 28, 2015 at 4:20 AM, Robert Parker wrote:
> I need to meet the requirements of 2 sets of users, the ordinary user who
> is only interested `./configure;
Did you try:
CPPFLAGS="$CPPFLAGS -DMACR..."
?
John
Sent via the Samsung GALAXY S® 5, an AT&T 4G LTE smartphone
Original message
From: "Andy Falanga (afalanga)"
Date:04/02/2015 5:04 PM (GMT-07:00)
To: automake@gnu.org
Subject: The right way to
the check programs being built - it merely specifies which
scripts/programs to run when tests are actually executed.
Regards,
John
On 3/12/2015 4:23 PM, Arthur Schwarz wrote:
Win7-64 bit
Cygwin 64-bit
g++ 4.9.2
I'm trying to link test program. The linker command option given to g++
during
Hello,
I'm wondering what the canonical way of providing my own compile/link
target are for sources with a particular suffix.
If I have a language foo (interpreted) and a byte compiler fooc how do I
best achieve what would be done equivalently in a C based Makefile.am.
I'd like to take advantage
tool.
Indeed, I've found these guys to be quite amenable to adding new build
paradigms to automake's repertoire.
I'm glad you found a solution that works.
On Sep 1, 2013 3:36 PM, "Sergey 'Jin' Bostandzhyan"
wrote:
> John,
>
> On Sun, Sep 01, 2013
so hard to fix.
Be aware that you're kicking against the pricks (as the old saying goes).
Sooner or later you'll run into other issues with new versions of automake
that may not have such simple resolutions.
Regards,
John
On Sep 1, 2013 11:53 AM, "Sergey Jin' Bostandzhyan"
r extensions as well.
John
f that.
So, at least on a personal level, I am strongly opposed to rolling
libtool into automake.
John Bytheway
re correct - that's often
the problem with errors like this.
Regards,
John
> -Original Message-
> From: automake-bounces+john.calcote=gmail@gnu.org
> [mailto:automake-bounces+john.calcote=gmail@gnu.org] On Behalf Of
> Del Merritt
> Sent: Wednesday, August 1
t.
Forgive my ignorance (because I'm *sure* I'm missing something crucial
here), but I don't believe this is a fair comparison, since GCC's use of
make doesn't appear (to me) to be in the same order as Automakes use of
make.
Regards,
John
tical to a library identical: A
library is an archive of objects. A jar is an archive of objects. Jar's
happen to be compressed as well, but that's irrelevant. Conceptually,
they're the same.
I would argue in favor of different names for political reasons. :) There's
still a fairly large rift between C/C++ and Java developers.
--john
this second item is done. One of the
inherent benefits of recursive make is that there's a self-contained
Makefile in each directory. Thus, you can run make from that directory.
I'm wondering how you do that with only one top-level Makefile.
--john
static
version of your library from your environment (/usr/lib or /usr/local/lib).
My assumptions may all be wrong - especially in light of the fact that
bin_PROGRAMS seems to work the way you want it to...
John
gives the error:
configure.ac:336: required file `po/Makefile.in' not found
Makefile.am:5: AM_GNU_GETTEXT used but `po' not in SUBDIRS
There are ways to circumvent this of course. But I think that automake should
not do this if subdir-options is specified in AUTOMAKE_OPTIONS
Regar
On 11/21/2010 07:09 PM, Miles Bader wrote:
> John Calcote writes:
>> You need to remember the original target audience of GNU software was
>> a group of people that wanted to share free software. Most of them
>> were students or researchers that generally built software dis
a good assembly debug session.
In any case, it makes complete sense why the GNU standards were written
this way when you understand the history.
John
On 11/21/2010 12:25 PM, MK wrote:
> On Sun, 21 Nov 2010 17:44:10 +0100
> Ralf Wildenhues wrote:
>> Oh well. This thread has been so noisy
On 8/16/2010 9:06 AM, Bob Friesenhahn wrote:
> On Sun, 15 Aug 2010, John Calcote wrote:
>>
>> The warning you're seeing is harmless enough on platforms that support
>> GNU make. The purpose of the warning is to let you know that your users
>> will not be able to bu
The warning you're seeing is harmless enough on platforms that support
GNU make. The purpose of the warning is to let you know that your users
will not be able to build your project on systems that support the
Autotools, but do not support GNU make (not many these days).
Regards,
John
#x27;s the purpose of "specifying the condition that is closed"? I've
> never seen this kind of construct before. Is it a substitute for
> elseif?
>
Documentation. There may be several dozen lines of code between the if
and the else. A reader may be wondering... else what?
John
tribution
package, along with the cleanup. If the temporary directory contains
anything other than the dist package's sources after "make clean" is run
by the test, you'll get a dist error.
John
libs" && rm -f "libfoo.so.0" && ln -s
"libfoo.so.0.0.0" "libfoo.so.0")
libtool: link: (cd ".libs" && rm -f "libfoo.so" && ln -s
"libfoo.so.0.0.0" "libfoo.so")
libtool: link: ar cru .libs/libfoo.a foo.o
libtool: link: ranlib .libs/libfoo.a
libtool: link: ( cd ".libs" && rm -f "libfoo.la" && ln -s "../libfoo.la"
"libfoo.la" )
$
I don't know how QT resources are used by source code, but this may be
the more correct way to place the dependency anyway. If QT resources are
somehow "included" in the c sources, then this dependency is more
accurate. If they're just linked into the final library, then the
dependency should be placed between the library and the resource.
John
build - they'll tell you what object files are being
generated from your sources and where they're being put.
John
27;s sake:
.../lcairo.$(OBJEXT) : resource.qt
This is why most people just use BUILT_SOURCES - it's cheating but it
works for most cases. (See section 9.5 of the Automake manual for more
info on BUILT_SOURCES).
John
check", or
"make install". But if a user types "make somefile.o" or attempts to
build the executable or library directly, then any qt files that
somefile (or that executable or library) happens to require will not get
built beforehand.
John
On 6/20/2010 12:56 PM, Wesl
ndir)|g' \
-e 's|@syslogd...@]|$(syslogdir)|g' \
-e 's|@libexecd...@]|$(libexecdir)|g' \
-e 's|@sbind...@]|$(sbindir)|g'\
-e 's|@pref...@]|$(prefix)|g'
all: myprog.cfg
# Build executable scripts
myprog.cfg : Makefile
$(edit) '$(srcdir)/$...@.in' > $@
Then just format your input templates just like autoconf input templates
with @variable@ where ever you want variable replacement to occur at
make time.
Regards,
John
Hi Steffen,
On 4/19/2010 1:22 PM, Steffen Dettmer wrote:
On Mon, Apr 19, 2010 at 8:25 PM, John Calcote wrote:
[...]
Builds in the Java world generally specify source files found
within a subtree using a globbing mechanism, with optionally
specified inclusions and exclusions.
Yes
ity
available, in the form of a JVM and javac compiler. Just a thought.
One thing we can do at this point is to define JAR and WAR primaries
that build and install (in appropriate locations), .jar and .war files.
I've got a few ideas I'll try to codify and send out shortly.
John
t sub-directories. The resulting object files
are named the same, and stored in the same directory, so there's a
conflict. He's tried using the automake option to generate objects in
the source directory, but that didn't work for reasons he outlined (but
I wasn't clear on).
John
n method header comments to their
source code, which means there's often no concept documentation, just
method documentation, which is useless to people trying to learn the
API. This isn't always true. Some projects try hard to add concept docs
too, but just very few by comparison.
Just a comment.
John
hanks very much for the positive feedback. A much enhanced (and
somewhat corrected) version of the book is scheduled to be published in
May 2010 by No Starch Press:
http://www.amazon.com/Autotools-Practioners-Autoconf-Automake-Libtool/dp/1593272065
Best regards,
John
After that, i could
(./program -c testconfig.ini).
I love the flexibility this system provides, and I don't see any
security issues with it, unless your program must be run as root in
order to do what it needs to do. In that case, it's not safe to execute
it during make check anyway. But it can be executed during make
installcheck.
John
On 3/3/2010 12:53 PM, Russ Allbery wrote:
John Calcote writes:
While I agree that standards should be followed, I find this one
distasteful. I mean, "long long"? Is that supposed to be someone's idea
of a scalable solution? What happens when we have 128-bit systems? Dare
I
Sorry - I addressed this note to Jef. It should have gone to Ben. My
apologies.
On 3/3/2010 12:16 PM, John Calcote wrote:
Hi Jef,
On 3/3/2010 11:53 AM, Ben Pfaff wrote:
Jef Driesen writes:
It works fine for every system I have access too, but long long is not
standard and thus not
e standard already defines such types for the more commonly used
sizes, and it is scalable.
John
y executing gcc with linux32).
Another way to use your 64-bit gcc without special compiler flags is to
create scripts, named with the cross prefix, in your bin directory that
execute the compiler in 32-bit mode (and perhaps also executed by
linux32). Then these tools will be preferred by Autoconf when you use
--host=.
Regards,
John
ticular check program (perhaps as
I'm working out the compiler errors, but before I'm ready to actually
run the tests), I just type "make " from that
directory. Alexander's solution is great, though. I'm going to use that
one myself.
Regards,
John
Hi Ralf,
On 2/6/2010 9:32 AM, Ralf Wildenhues wrote:
Hello,
to round up a couple of minor bits here:
* John Calcote wrote on Wed, Feb 03, 2010 at 05:57:49PM CET:
The trouble with LIBRARIES is that it only builds non-PIC static
libraries, which can't be linked into a libtool s
Steffan,
On 2/3/2010 5:50 AM, Steffen Dettmer wrote:
On Wed, Feb 3, 2010 at 8:33 AM, John Calcote wrote:
(PIC-based static only) library is to use the "noinst" prefix. But libtool
can be used to manually install a convenience library, so you could use
libtool to do this in an in
his in an install-exec-local rule in the
Makefile.am file that builds (for instance) libhello.a (untested):
install-exec-local:
libtool --mode=install ./install-sh -c libhello.a
$(DESTDIR)$(lib)/libhello.a
This example came from the libtool manual (modified slightly for
Automake context).
Regards,
John
;s windows don't have curtains.
John
rules in Automake Makefile.am files to put
these files in the right locations. Be aware, however, that the more of
this activity you do in your Automake makefiles, the less portable
they'll likely be.
Regards,
John
ly loaded just like
.so files on Solaris or Linux. The .a files also contain the static
objects linked into a binary when static linking is requested.
Regards,
John
On 9/28/2009 7:09 PM, John Calcote wrote:
Bruce,
On 9/28/2009 7:03 PM, David Bruce wrote:
Sorry David, then I went and got your first and last names mixed up.
Perhaps I'd better just be quiet now. ;)
alized it was a period, but figured it must have been
inadvertently inserted during cut and paste into your email. If I'd
responded when I thought to, I might have saved you some time.
Regards,
John
to keep the code private.
Please share at least one of your Makefile.am files with us - preferably
the one containing the _SOURCES directive that you modified.
Thanks,
John
sts in the same
directory as the Makefile.am file you've shown? That's where it should
be without a relative path prefix.
Regards,
John
On 8/17/2009 1:22 AM, Mick wrote:
I'm trying to rebuild my application using the current(ish) glade and
autoconf/automake and have been having a nightm
Sorry - I forgot to give the relative path in the pic_DATA variable
below - here's the corrected version:
picdir = $(datadir)/pics # assuming you want png's installed in
/usr/local/share/pics
pic_DATA = pics/mypicture.png
then try to build on
standard places defined in the automake provided environment variables.
Regards,
John
On Wed, Aug 5, 2009 at 8:04 PM, John Wohlbier wrote:
> I'm using libtool in a project where I'm compiling code for the cell
> processor. The cell requires different compilers to be used on sources
> compiled for the PowerPC core (PPU) and the "synergistic processing uni
le.am file. This is wrong - the comps hierarchy
should be built before the apps hierarchy, or else there will still be
no libraries in the comps hierarchy for the apps to link against, unless
you've manually built the comps directory first, and then attempted to
build from root.
Regards,
John
Hi Ben,
The reason this works is because of the way AM Conditionals are
implemented. If a conditional is true, then all contained statements are
in effect. Otherwise, all contained conditions are commented out in the
resulting makefile.
Regards,
John
On 7/29/2009 8:57 PM, Ben Pfaff wrote
which is not supposed to be a comment. Just
shooting in the dark now...
发件人: John Calcote [mailto:john.calc...@gmail.com]
发送时间: 2009年7月24日 14:28
收件人: A117
抄送: Automake@gnu.org
主题: Re: how to install library in a specific directory?
On 7/24/2009 12:21 AM, A117 wrote:
lib_LTLIBRARIES = libezcomm
Try replacing the TAB characters at the beginning of your wrapped lines
with spaces. And also make sure you don't have any white-space following
any of the back-slashes at the end of wrapped lines.
John
- -
On 7/23/2009 7:45 PM, A117 wrote:
Sorry I forgot to mention the fil
posted to determine the cause. Can you post the
entire Makefile.am file? Or at least a smaller example that reproduces
the problem. There's nothing that I can see in the portion of your file
that you posted that would be the cause of such a problem.
John
ibraries.
When you add a new library to one of the directories in /etc/ld.so.conf,
then you need to run ldconfig to ensure that the cache is aware of that
new library.
John
new library to one of the directories in /etc/ld.so.conf,
then you need to run ldconfig to ensure that the cache is aware of that
new library.
John
file, then use pkgconfig to
locate the library.
Regards,
John
On 7/10/2009 5:42 PM, Andrew W. Nosenko wrote:
On Fri, Jul 10, 2009 at 20:52, John Calcote wrote:
2) Is there any movement within the Automake community to move toward the
LSB directory structure as the default?
Excuse me, but why automake should prefer one of the many OS and
is.
Sorry for the confusion...
John
any movement within the Automake community to move toward
the LSB directory structure as the default?
Thanks in advance,
John
irectories (your own) as maintainer code, and other directories (your
third-party directories) as user code.
Regards,
John
oject.
Just curious - under what conditions do you have a header file in the
local directory that you need to have overridden by a globally installed
header file?
Regards,
John
John,
On 6/29/2009 2:00 PM, johnwohlb...@gmail.com wrote:
On Jun 29, 2009 1:44pm, Ralf Wildenhues wrote:
Hello John, Thanks Ralf. I feel pretty dumb. You know I suspected
that was the problem, and was trying to cd ../. But now I realize I
was putting the cd ../ in the wrong place. After my
Hi John,
On 6/29/2009 1:44 PM, Ralf Wildenhues wrote:
Hello John,
* johnwohlb...@gmail.com wrote on Mon, Jun 29, 2009 at 09:36:09PM CEST:
in top/lib/Makefile.am
SUBDIRS = pika_comm pika_utilities
# provide a separate recursive target for making tests
tests : all
echo `pwd`;
for dir in
never occurred to me that Automake would look
inside the texi file to determine the name of the output file, but it
makes sense. I copied this sample file from the texinfo manual as a
quick input file, but didn't check the contents that closely.
Thanks for the tip.
John
ardoz.tp zardoz.tps zardoz.vr zardoz.vrs \
sample.dvi sample.pdf sample.ps sample.html
rm -f *.o
It looks like the last line should contain:
zardoz.dvi zardoz.pdf zardoz.ps zardoz.html
Regards,
John
Thanks again for the help Ralf.
>
> If that still doesn't help, it is useful to post a small example
>
> package.
>
Attached is an example package. What I left out of my original email was
that I'm putting the Makefile.am's out of the src/ directory to enable
building other architecture specific
ks in advance,
John
ut to /dev/null, that is). At least, that's one reason why, for
several years now, I've advocated an Autotools option for silent builds.
Regards,
John
On 5/6/2009 3:15 AM, Andreas Schwab wrote:
John Calcote writes:
One thing that bothers me a little is that we never really did solve
Gerald's original problem. He said his library was created just fine when
he was passing 2:0:0, but when he switched to 2:0:1, it created a library
w
Hi Ralf,
On 5/5/2009 2:46 PM, Ralf Wildenhues wrote:
Hello,
I think most issues were already cleared up in this thread.
* John Calcote wrote on Sun, May 03, 2009 at 06:58:09PM CEST:
It appears that Libtool is smart enough to detect ridiculous cases, but
it should probably throw an error
you need from pthread and libgsl at
run-time. This will clear the hard dependency on these other libraries.
And if you call these 8 routines only 2 percent of the time, then it
will also clear soft dependencies for your users 98 percent of the time.
Regards,
John
0, but the OS loader can only find 2.0.1, then the loader will go
ahead and load 2.0.1 because the '1' in the age field indicates that
this library supports 1.x interfaces as well as 2.x.
Jan answers the rest of your question in his response.
Regards,
John
imply
generate code with a different version number.
Adding the libtool list.
Regards,
John
tive. :(
That's been my experience, as well. I think there aren't enough folks
who blog about the Autotools. This is probably because the class of
people who blog simply doesn't overlap much with the class of people who
use the Autotools. ;-)
Regards,
John
The automake manual says:
Sometimes an info file actually depends on more than one .texi
file. For instance, in GNU Hello, hello.texi includes the file
gpl.texi. You can tell Automake about these dependencies using the
texi_TEXINFOS variable. Here is how GNU Hello does it:
info_TEXINFOS
report did not receive any replies.
I believe this should work, there's no reason for it not to that I can
think of, but I'm wondering: Why would you create texinfos, and then not
install them? This is probably how the bug got there - it's not a very
likely use case, is it?
John
See my online Autotools book at freesoftwaremagazine:
http://www.freesoftwaremagazine.com/books/autotools_a_guide_to_autoconf_automake_libtool
Chapter 4 is all about automake. This book is due to be published by No
Starch Press in October 09.
John
On 4/24/2009 12:16 AM, automake wrote
-targets?
Sure, just add it to the all-local target as a dependency, like this:
all-local: extra
--john
On 4/20/2009 3:49 PM, Peter O'Gorman wrote:
John Calcote wrote:
On 4/18/2009 3:08 PM, LCID Fire wrote:
I'm currently stuck with compiling a JNI library, which java does not
recognize. I'm not too sure about what options I have to provide to
automake and which are
:
http://www.freesoftwaremagazine.com/books/agaal/autotools_example
Search for the text, "Building the JNI C++ sources".
Regards,
John
pty.". Doing anything based on whether the directory itself was empty
is meaningless, because the maintainer may have chosen to use the pkglib
directory, for example, in which case, it will almost always be empty
before you install - even to standard places - unless you're overwriting
a previous installation, that is.
John
the topic you're interested
in (doxygen).
A much-updated version of this book will be published later this year by
No Starch Press.
Regards,
John
On 4/12/2009 4:17 AM, Lorenzo Bettini wrote:
Hi
I've just started using doxygen for documenting a C++ library which
I'm
http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=fcf62c3d
Yes, I thought this might have been the trick you used: AC_DEFUN a macro
with no expansion in the same file, just to get aclocal to include it.
Way to work around the rules! :-)
Regards,
John
On 4/3/2009 5:31 PM, Ralf Wildenhues wrote:
Hi John,
* John Calcote wrote on Fri, Apr 03, 2009 at 09:33:40PM CEST:
On page 158, paragraph 3 of the 2.63 Autoconf manual, it states:
"If a macro doesn’t use AC_REQUIRE, is expected to never be the object
of an AC_REQUIRE directive, and m
f AC_DEFUN,
rather than m4_define in stand-alone .m4 files.
Is this a bug in aclocal?
I'm using the latest beta version of Automake - 1.10b.
Thanks in advance,
John
ve should work. Each failed test is listed in full in config.log,
along with the output of the compiler and linker, so you can probably
easily see why the test failed.
Regards,
John
LIBRARIES instead of noinst_LTLIBRARIES.
Check libraries and programs are not installed either.
Regards,
John
y paths, the build will fail with a
linker error. The entire purpose of Autoconf checks is to ensure that
the environment is actually able to build the project. If this solution
is acceptable to you, then why even bother with configure? Why not
simply write a makefile to build your project?
Regards,
John
ve should work. Each failed test is listed in full in config.log,
along with the output of the compiler and linker, so you can probably
easily see why the test failed.
John
even if you
supply the "action-if-found" argument. All of it's success functionality
is given by the default value of the argument. Thus, if you supply the
argument, you have to supply all of the appropriate functionality for a
successful check. In this case, the macro is supposed to prepend
-lproject to LIBS, and then define HAVE_LIBPROJECT.
Regards,
John
7;t like. But the -fPIC builds were
silenced.
Is there any command-line option for configure and/or make that will
keep libtool from hiding half the compiles? (Odd that I, of all people,
should ask for this, since I was one of the original proponents of
silent builds!)
:)
John
On 4/1/2009 1:32 PM
make -C ../keysyms
/Makefile.am should contain:
SUBDIRS = ... keysyms ... src ...
Just makesure keysyms is given before src in that list.
Regards,
John
1 - 100 of 252 matches
Mail list logo
