Re: automake variable prefix 'check_'

[John Calcote]

On Tue, Feb 2, 2021 at 11:46 AM Zack Weinberg  wrote:

> On Tue, Feb 2, 2021 at 1:24 PM DUDZIAK Krzysztof
>  wrote:
> > As one can't find string "distcheck" in GCS
>
> By GCS do you mean the GNU Coding Standards?
>
> > it looks like it wasn't GCS
> > which constitutes support and usage of `distcheck' target.
> > Maybe it is POSIX, or UNIX.
>
> As far as I know, the distcheck target was invented by automake. It
> probably should be added to the GNU Coding Standards, if it's not
> there already, but I don't know 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 this book. Since it was published ten years ago,
> anything it describes may well be out of date.  I don't think
> distcheck has changed much in that time, but I could be wrong.
>
>
The second edition was published in 2019, so more like a year and a half
ago.
It's pretty up to date even with 2.70 as I tried to consider changes that
had been made in
the repository that had yet to be published.

John

Re: PLV, PSV in manual

[John Calcote]

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
>  wrote:
> > Isn't it that strange if for manual* following searches for a string
> result in no matches?
> > search for "PLV"
> > search for "PSV"
> > search for "Product List Variable"
> > search for "Product Source Variable"
>
> I've never heard these terms before and don't know what they mean. Can
> you please explain what these terms mean and what you expected the
> automake manual to have to say about them?
>
> zw
>
>

Re: Future plans for Autotools

[John Calcote]

Zack,

On Thu, Jan 21, 2021 at 9:12 AM Zack Weinberg  wrote:

> On Wed, Jan 20, 2021 at 5:15 PM Zack Weinberg  wrote:
> > Now we've all had a while to recover from the long-awaited Autoconf
> > 2.70 release, I'd like to start a conversation about where the
> > Autotools in general might be going in the future.
>
> > Now we've all had a while to recover from the long-awaited Autoconf
> > 2.70 release, I'd like to start a conversation about where the
> > Autotools in general might be going in the future.
>
> Thanks for all the great thoughtful responses that came in overnight!
> I see many people expressing similar sentiments, so rather than
> respond to each of you individually I'm going to summarize and reply
> to each strand in this one message.
>
>
I like the way you think. But, as your response so clearly indicates,
there's actually very little we can change in a radical way:

1. We shouldn't change the underlying language(s) and tools because one of
the key strengths of the Autotools is (their products') ability to run
everywhere without off-box dependencies. In my humble opinion, nothing the
GNU project has ever done comes close to the value they created by
designing the Autotools to work as seamlessly (for the end-user) as they
do. Download a tarball, unpack, ./configure && make. How much simpler could
it be? No additional tools to install - everything required is already
there - for the end user. Of course, developers may need to install a few
additional tools to build these tarballs from the base source repository,
but developers are not end-users and those are the "customers" GNU was
trying to appease. If you build from source repositories, you're
effectively a developer, not an end-user - not always the case, but 98% of
the time this is true.

Additionally, making such changes would require long man-hours of unpaid
effort - something the world is not willing to give. Gone are the days of
university grad students who know enough of what they're talking about to
effectively take on this task for the sake of their educational goals (this
is the way these tools started, after all). In fact, as much as they'd hate
to admit it, the GNU project has become much more corporate than
educational today. But let's not get bent out of shape by it - the truth of
the matter is that no one does anything for free (you yourself solicited
funding for the 2.70 update - which did NOT ultimately come from
philanthropic individuals.

2. The Autotools are actually more transparent than any other build tools
out there. All these other tools' (cmake, maven, etc) - that purport to be
so much simpler because they insulate the user from the underlying details
of the build process - these tool's primary failure is that this very
insulation keeps users from being able to make the changes they need to
accomplish their unique project-specific build goals.

Anyone who has nothing but good things to say about this aspect of cmake,
maven, gradle, or whatever, has simply not worked on a project that
requires them to move far enough away from the defaults. I've used them all
and I've spent hours in frustration trying to determine how to work around
the shortcomings of some "do-all" (except what I want) tool function. This
is simply not an issue with the Autotools. As someone mentioned earlier in
this thread, you can drop shell script into a configure.ac file, and make
script into a Makefile.am file. That is the very definition of
transparency. No other tool in existence allows this level of flexibility.

The most interesting feedback I read in the responses was that the
Autotools had an appalling lack of documentation which - ironically - is
actually not true. At the risk of sounding self-serving, I'll say this: in
the research I did for my book (Autotools, No Starch Press, 2019), I
primarily (95%) used the GNU Autotools documentation as reference sources.
The information is all there and actually very concise - too concise
sometimes. The problem with it is two fold.

First, the documentation for GNU projects is most often written by the
author of the code - that's the open source way, after all. This brings
with it all sorts of issues that most corporate documentation
(inadvertently) bypasses by standard corporate siloing protocol - that is,
they relegate doc writing to doc writers, who are often not experts in the
code, so they have to spend the time researching the product from a user's
perspective. This is exactly the perfect storm of events that (usually)
generates pretty good documentation.

Second, the documentation is written in a manner that is not conducive to
fast learning. There are two types of instructive material. The first is
reference material that, by its very nature, requires the user to read and
absorb significant amounts of information until they hit a critical mass of
understanding - an exponential learning curve that starts out long and slow
- at which point they avalanche into the steeper portion of the curve. 

Re: Stopping unit test on failed partial ordering dependency

[John Calcote]

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

>

Re: Makefile.in, LIBTOOL and shared/static builds.

[John Calcote]

On Sat, Jun 23, 2018 at 1:00 AM or...@fredslev.dk  wrote:

> Hi,
>
> I am using the GNU libtool alternative slibtool which has some benefits
> such as a smaller code base, actively maintained and a huge performance
> boost.


I’m curious - it’s neat that slibtool exists, but if you need functionality
offered by libtool then why not just use libtool?

John

>

Re: [GSoC] Proposal for "Parse Makefile.am using an AST"

[John Calcote]

Hi Matthias,

If you have any suggestions on documents I can read or software I can check
> to
> prepare for this project I'll be glad to check them. I know texinfo is
> written
> in Perl and generates an AST so I'll check that.
>

A Makefile.am file is really just a Makefile with embellishments. It seems
like your ast would have to incorporate most of make’s syntax to work
correctly.

The reason Perl was chosen to begin with is because of its great text
processing capabilities as, ultimately, all automake really does is copy
the file directly to the output Makefile.in file, filtering out automake
stuff along the way and injecting make snippets generated from the automake
constructs.

This may not appear obvious at first because many simpler Makefile.am files
contain only automake stuff. But anything found in the Makefile.am file
that automake doesn’t recognize 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

Re: What is minimum set of Automake work files needed for distribution on github?

[John Calcote]

Hi Robert,

The Autotools were created to meet a specific need - that of the open
source distribution model supported by many open source projects where,
occasionally - or perhaps nightly, the project maintainers would release a
source tarball containing a configure script and Makefile.in files. As a
regular user, you'd want to just download a tarball, extract, and run
./configure && make.

However, as a potential contributor, you'd want the source repository so
you could create patches against the tip of a particular branch. So you'd
clone the source repository and use the Autotools to create a configure
script for yourself in your repository work area.

Thus, the usual technique is to commit the Autotools source files required
by your project, but to NOT commit a configure script. Anyone wanting to
clone your repository is expected to be "developer enough" to know how to
run "autoreconf -i" to create the configure script.

While you CAN commit a configure script, it generally causes more problems
than it solves, as you find yourself committing an updated configure script
for lots of little project changes. Regardless, many projects do this -
especially lately on projects hosted by github, mainly (I believe) because
github has defined a new trend in the open source world where "regular
users" tend to get the source from the repository rather than from a
tarball, more often than not these days.

Here's a resource you 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; make; make install` and the power users
> who want to start with `autoreconf`.
>
> So far google search on the topic has only increased my confusion.
>
> --
> The Bundys, Cliven, Ted and Al. Great guys to look up to.
>

RE: The right way to use standard variable in configure.ac

[John Calcote]

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 use standard variable in configure.ac 

Hi,

I placed the following in my configure.ac file:

CPPFLAGS="-DMACRO1 -DMACRO2"

because I found that as an example on a webpage someplace.  I reviewed so many 
learning about the autotools that I don't recall which one now.  I did this 
because there were some preprocessor flags that I wanted to have common to all 
sub-makefiles.

I ran into a problem today, however, where I needed to add a -I directive to my 
CPPFLAGS in order to find the necessary headers.  Then, the problem stepped in. 
 Because I placed this line in configure.ac, it was transcribed, verbatim (as 
it should), into configure.  The net result: not matter what I placed on the 
command line was ignored.  For example, the following:

CPPFLAGS=-I/path/to/the/alternate/location ./configure --build=x86_64-linux 
--host=arm-poky-linux-gnueabi

The additional path wasn't being appended, it was being stomped.  Did I miss a 
macro?  How should this be done because, obviously, I've gotten it incorrect.

Thanks,
Andy

Re: Wrong link option given to g++

[John Calcote]

Hi Arthur,

Look carefully at your configure.ac file or any scripts calling your 
makefile. See if you find anyone setting CFLAGS, CPPFLAGS, etc on the 
way in. They maybe adding -c (erroneously) to these variables.


To answer your question, the TEST macro should be completely independent 
of 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 'make check' says "don't link". Any way around this?


check_PROGRAMS = test
test_INCLUDE   = -I$(top_srcdir)/src
test_SOURCES   = $(testCPP) $(testHead)
test_LDADD = libslip.a

'make check' contains:
g++ -std=gnu++11 -Wall -Wno-reorder -Wno-unused-value -Wno-address
-Wno-sequence-point -Wmaybe-uninitialized -c -g  -o test.exe Test.o
TestErrors.o TestGlobal.o TestHeader.o TestIO.o TestMisc.o TestOperators.o
TestReader.o TestReplace.o TestSequencer.o TestUtilities.o  libslip.a

which works when the "-c" option is removed.

g++ --help  =>  -c  Compile and assemble, but do not link


Is the linker command supposed to be given in a test script in the
Makefile.am file (TEST=script)?


The failure of the past is the challenge of the present and the success of
the future.

Re: problem with subdir-objects and not found .Plo files when migrating to 1.14

[John Calcote]

Don't get me wrong - I have nothing against your approach. And the automake
maintainers are certainly not purposely trying to make things more
difficult for you. I merely suggest that you may run into more issues down
the road simply because supporting your setup is not a current goal of the
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 at 03:11:11PM -0600, John Calcote wrote:
> > I'm curious as to why it's important to you that build products not land
> in the
> > source tree, especially in light of the fact that you're clearly aware of
> > automake's support for out-of-tree builds. Out-of-tree builds exist to
> solve
> > the very problem you're trying so hard to fix.
>
> well, consider the following: your project has several source
> subdirectories,
> some of them with two levels. Even with out of tree builts you end up
> having the produced libraries and executables in each of those
> subdirectories
> respectively, or in other words: all over the place. Sure, you can do a
> make install to get all things together, but that's not always practical
> during development.
>
> My setup dumps all the compiled stuff into one directoriy, which makes it
> really easy to find, it's just more convenient.
>
> Honestly, if you have a choice, do you really prefer having the binaries
> all
> in different places in your tree?
>
> Also, I don't have to go out of the project dir when I want to "make"
> which I would have to do if I configured out of tree.
>
> What's wrong with that approach? People who use my setup seem to like it,
> as I said, it's convenience, no matter if used with in or out of tree
> builds.
>
> > 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.
>
> I wonder why the authors of automake would try to restrict different and
> actually valid usage scenarios? I've been using this setup for over 5 years
> in different projects, I'd be really disappointed if I had to switch to a
> setup that is much more inconvenient for me.
>
> Please don't become another Gnome 3 by enforcing weird restrictions upon
> your
> users ;) Or is there really a hard technical limitation that would make
> setups as above impossible? I can't believe that... so I hope I will have
> the freedom of choice, also with newer versions of automake.
>
> Kind regards,
> Jin
>
>
> > On Sep 1, 2013 11:53 AM, "Sergey Jin' Bostandzhyan" 
> wrote:
> >
> > Hi,
> >
> > OK, never mind, problem solved. It seems that $(top_srcdir) simply
> did not
> > expand anymore in _SOURCES. Keeping my structure with the
> build/Makefile.am
> > but replacing $(top_srcdir) with '..' did the trick, it works
> > like a charm now, including in and out of tree builds.
> >
> > No more warnings, no more not found .Po files, and I get my binaries
> and
> > libraries nicely in the build directory without polluting the source
> tree.
> >
> > Kind regards,
> > Jin
> >
> > On Sun, Sep 01, 2013 at 06:45:32PM +0200, Sergey 'Jin' Bostandzhyan
> wrote:
> > > Hi,
> > >
> > > thanks for your reply, some more questions though:
> > >
> > > On Sun, Sep 01, 2013 at 03:08:37PM +0100, Diego Elio Petten  wrote:
> > > > Is it possible to keep the logic with the in-tree build
> directory
> > with
> > > > automake 1.14? I did try to move all the logic from build/
> > Makefile.am into
> > > > the top level Makefile.am and removing build/Makefile.am
> > completely, but
> > > > it does not help - .Plo files are not found.
> > > >
> > > >
> > > > I'd say it's a very bad idea to use that build/Makefile.am.
> > >
> > > Could you please elaborate? I'd be interested in the technical
> details on
> > why
> > > it is a bad idea?
> > >
> > > > Move the includes on the top-level Makefile.am, and get rid of $
> > (top_srcdir) on
> > > > all the _SOURCES declaration and it should work fine.
> > >
> > > It does compile now, and it does dump all the .o and .lo and what
> not
> > > in the same directory as the sources - very ugly. This is exactly
> what I
> > was
> > > avoiding with the separate build directory and it worked just
> perfectly
> > > until automake 1.14 came along.
> > >
> > > Is there any way to tell 1.14 to place the object files into some
> > dedicated
> > > directory without doing an actual "out of tree" build, or in other
> words,
> > > can I achieve the same setup that I had on 1.14 somehow?
> > >
> > > Kind regards,
> > > Jin
> > >
> >
> >
>

Re: problem with subdir-objects and not found .Plo files when migrating to 1.14

[John Calcote]

Sergey,

I'm curious as to why it's important to you that build products not land in
the source tree, especially in light of the fact that you're clearly aware
of automake's support for out-of-tree builds. Out-of-tree builds exist to
solve the very problem you're trying 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" 
wrote:

> Hi,
>
> OK, never mind, problem solved. It seems that $(top_srcdir) simply did not
> expand anymore in _SOURCES. Keeping my structure with the build/Makefile.am
> but replacing $(top_srcdir) with '..' did the trick, it works
> like a charm now, including in and out of tree builds.
>
> No more warnings, no more not found .Po files, and I get my binaries and
> libraries nicely in the build directory without polluting the source tree.
>
> Kind regards,
> Jin
>
> On Sun, Sep 01, 2013 at 06:45:32PM +0200, Sergey 'Jin' Bostandzhyan wrote:
> > Hi,
> >
> > thanks for your reply, some more questions though:
> >
> > On Sun, Sep 01, 2013 at 03:08:37PM +0100, Diego Elio Pettenò wrote:
> > > Is it possible to keep the logic with the in-tree build directory
> with
> > > automake 1.14? I did try to move all the logic from
> build/Makefile.am into
> > > the top level Makefile.am and removing build/Makefile.am
> completely, but
> > > it does not help - .Plo files are not found.
> > >
> > >
> > > I'd say it's a very bad idea to use that build/Makefile.am.
> >
> > Could you please elaborate? I'd be interested in the technical details
> on why
> > it is a bad idea?
> >
> > > Move the includes on the top-level Makefile.am, and get rid of
> $(top_srcdir) on
> > > all the _SOURCES declaration and it should work fine.
> >
> > It does compile now, and it does dump all the .o and .lo and what not
> > in the same directory as the sources - very ugly. This is exactly what I
> was
> > avoiding with the separate build directory and it worked just perfectly
> > until automake 1.14 came along.
> >
> > Is there any way to tell 1.14 to place the object files into some
> dedicated
> > directory without doing an actual "out of tree" build, or in other words,
> > can I achieve the same setup that I had on 1.14 somehow?
> >
> > Kind regards,
> > Jin
> >
>
>

RE: Using convenience libraries with non-recursive make

[John Calcote]

Hi Del,

First, if you're building a pure convenience library (you don't want shared
objects), then save yourself a layer of complexity by removing libtool from
the equation - just use LIBRARIES instead of LTLIBRARIES in your Makefile.am
file. Second, make sure all your relative paths are 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 15, 2012 9:27 AM
> To: automake@gnu.org
> Subject: Using convenience libraries with non-recursive make
> 
> I'm using automake 1.11.1 and autoconf 2.68.  I am switching from a set of
> hand-written Makefiles to autoconf/automake.  I'm switching to autotools
> since the support for cross-compilation is already there; my hand-written
> Makefiles are getting hard to manage, and they don't support VPATH builds
> cleanly.
> 
> I have a lot of source files (4K+) and a lot of libraries (40+).  My goal
is to
> generate a single (typically/initially static) library and an executable
that
> demos/drives it.  I am hoping to avoid a recursive make (SUBDIRS=...),
since I
> am holding to the "Recursive makefiles considered harmful" mantra.
> 
> A representative Makefile.am for my project is:
> 
> # Automake rules to build application.
> AM_CXXFLAGS = -I${includedir}
> ACLOCAL_AMFLAGS = -I m4
> bin_PROGRAMS = myprog
> myprog_SOURCES = b/c/d/myprog__main.cpp
> myprog_LDADD = libmyprog.la
> lib_LTLIBRARIES = libmyprog.la
> nodist_EXTRA_libmyprog_la_SOURCES = dummy.cxx
> 
> lib_LTLIBRARIES += liba_s1.la libb_s2.la libb_c_s3.la
libb_c_d_myprog.la
> 
> libmyprog_la_LIBADD =  liba_s1.la libb_s2.la libb_c_s3.la
> libb_c_d_myprog.la
> liba_s1_la_SOURCES = a/s1.cpp
> libb_s2_la_SOURCES = b/s2.cpp
> libb_c_s3_la_SOURCES = b/c/s3.cpp
> libb_c_d_myprog_la_SOURCES = b/c/d/myprog.cpp
> 
> And it's similarly-simple configure.ac:
> 
> AC_PREREQ([2.59])
> AC_INIT([libmyprog], [1.0], [d...@alum.mit.edu])
> AM_INIT_AUTOMAKE([foreign subdir-objects])
> AC_CONFIG_SRCDIR([a/s1.cpp])
> AC_CONFIG_HEADERS([libmyprogconfig.h])
> AC_CONFIG_MACRO_DIR([m4])
> AC_PROG_MKDIR_P
> AC_PROG_CXX
> AM_PROG_LIBTOOL
> AC_CONFIG_FILES([Makefile])
> AC_OUTPUT
> 
> The directory structure is similar to:
> 
> ./a/s1.cpp
> ./b/s2.cpp
> ./b/c/d/myprog.cpp
> ./b/c/d/myprog__main.cpp
> ./b/c/s3.cpp
> 
> and in my real project there's lots more source in each subdirectory, and
lots
> more nested subdirectories.  Yes, the source containing main() is down
deep
> in the structure; myprog.cpp instances some top-level classes, and
> myprog_main.cpp is just the main() that gets things rolling.
> 
> When ./configure and make, I get:
> 
> del@oyster ~/am $ make
> make  all-am
> make[1]: Entering directory `/home/del/am'
> make[1]: *** No rule to make target `libmyprog.lo', needed by
> `libmyprog.la'.  Stop.
> make[1]: Leaving directory `/home/del/am'
> make: *** [all] Error 2
> 
> With the legacy hand-written makefile my project builds just fine.  I'm
> looking for suggestions as to what I'm missing in my Makefile.am.  Note
that I
> can explicitly say:
> 
> $ make libb_c_s3.la
> 
> and I lo, that library's source(s) compile and link.  So part of the
generated
> Makefile is cool.
> 
> Thanks,
> -Del

RE: Could automake-generated Makefiles required GNU make? (was: Re: [gnu-prog-discuss] portability)

[John Calcote]

> > Rather, one GNU package could drop support for ordinary Make, and
see
> > how users react.  If the level of complaint is not too high, then
> 
> GCC dropped support for non-GNU make in version 3.4 (April 2004).
> 
> We could see how users reacted to that.

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

RE: bug#9088: Java support

[John Calcote]

Jack,

-Original Message-
From: automake-bounces+john.calcote=gmail@gnu.org
[mailto:automake-bounces+john.calcote=gmail@gnu.org] On Behalf Of Jack
Kelly
Sent: Monday, July 18, 2011 1:34 AM
To: Ralf Wildenhues
Cc: 9...@debbugs.gnu.org; automake@gnu.org
Subject: Re: bug#9088: Java support

On Mon, Jul 18, 2011 at 4:17 PM, Ralf Wildenhues 
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/6059488f38fc8a51d426d6
>> > 972eee6fdd1033d851/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'.

Actually...conceptually, a jar is identical 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

Re: GSoC project idea: non-recursive automake project

[John Calcote]

On 03/19/2011 01:45 PM, Harlan Stenn wrote:
> Pippijn wrote:
>
>> On Fri, Mar 18, 2011 at 05:26:58PM -0700, Harlan Stenn wrote:
>>> If there was a student interested in showing how "easy" it was to use
>>> automake to do non-recursive Makefiles for a project, I'd be willing to
>>> co-mentor and work with them to convert NTP to that sort of operation.
>> It's mostly trivial. How hard are GSoC projects supposed to be?
> I'll assume you have seen my reply to Ralf.
>
> From my POV, I have heard folks saying for a long time how "easy" it is
> to use automake to produce non-recursive Makefiles.  But I haven't seen
> this in practice, and on the (few) attempts I have made to figure it out
> myself and look for examples, I have not yet been able to find a really
> useful solution.
>
> What I think we'd want is a reasonably well-documented description of
> how to use automake to produce a source tree where one can:
>
> - run "make" from the top-level of the tree and all of the normal things
>   happen (and all of the normal targets work)
> - run "make" from a subdir, which would handle all of the normal targets
>   for that subdir, and would also automatically handle *all* of the
>   dependencies needed for the specified targets in that subdir (like
>   prerequisite libraries).

I'd be *very* interested to see how 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

Re: dynamic executables for check_PROGRAMS?

[John Calcote]

Hi Jeff,

On 02/17/2011 04:06 PM, Daily, Jeff A wrote:
> I wrote a profiling layer for my library utilizing weak symbols.  I thought 
> for starters it would be nice to profile some of my test programs, to make 
> sure things are working okay.  I'm using autoconf, automake, and libtool, so 
> I configured using --enable-shared --disable-static, however, my test 
> programs are not created as dynamic executables.  If I change my 
> check_PROGRAMS to bin_PROGRAMS, they are dynamic executables.  But, I can't 
> do this in production for obvious reasons.
>
> So, is there any way to create dynamic executables for my check_PROGRAMS?
>
> Jeff

The --enable/disable-static/shared flags apply only to building shared
or static libraries within your project. These flags don't have anything
to do with how executables are built except to limit or expand the
options available to programs built against internal libraries. To test
this assertion, create a simple project without libtool (don't call
LT_INIT in configure.ac). When you run ./configure --help, you'll see
that these options are missing entirely from the help display.

I assume when you say "dynamic executables" you're referring to test
programs built to use shared libraries created from within the same
project. If you're noticing that your test binaries are getting linked
against your static libraries, then something strange is happening in
your project: If you're using --disable-static and it's working proper
but your check_PROGRAMS are inclined to link with the (now non-existent)
static libraries then I have to ask: How are these static libraries
getting built? - After all, you disabled them.

Assuming you've got Makefile.am code like this:

   check_PROGRAMS = test1
   test_SOURCES = test1.c
   test_LDADD = ../mylib/mylib.la

Make sure test_LDADD is referring to the correct relative path to your
internally built .la file. If you're specifying mylib.a (or even
mylib.la) without a relative path, you may be picking up a 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

Re: reword documentation about symbol stripping

[John Calcote]

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 distributed
>> in source form.
> ...
>> That being the case, "users" were programmers, and programmers are
>> indeed helpless without debug symbols during a crash - that is, unless
>> you're one of those rare types that loves to dig into a good assembly
>> debug session.
> I think the basic goal is still quite valid though -- the point is not
> to _require_ that users be programmers, or even to _expect_ them to be,
> but to _enable_ them to go as far as they want to go.  So In cases where
> some extra power can be granted to the user at little cost, it's good to
> do so, even if many users never use that power.
>
> The concept of system utilities/libraries/etc of being "magic you're not
> supposed to touch or look at, even if you want to" has been a problem
> for decades, though the lines have shifted.

Don't get me wrong - I completely agree with you. I like this approach
personally but perhaps that just because I'm a programmer myself.
Regardless, there is always value in providing a lot of information (as
long as it doesn't get in the way of normal use - and it most definitely
doesn't in this case).

Additionally, in the open source community, where user feedback is
essential, its important to empower users to give you valuable
information about your product - such as stack traces with symbols. So
even if you don't debug problems yourself, you can hardly give good
crash reports without symbol information - especially in a situation
where the developer can't know the binary version well enough to apply
symbols to numeric addresses correctly every time (as the user may have
received his version of your program from any number of sources that may
have modified it themselves).

John

Re: reword documentation about symbol stripping

[John Calcote]

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 distributed in
source form. Only in the last 10 years has Linux become generally
popular. Before that time, it and all the software that ran on it were
pretty much relegated to programmers. That being the case, "users" were
programmers, and programmers are indeed helpless without debug symbols
during a crash - that is, unless you're one of those rare types that
loves to dig into 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 and unproductive, maybe we
>> should seize the opportunity to take a bit of good away from it.
>>
>> Karl, what do you think about this rewording (against the gnulib copy
>> of make-stds.texi) that makes the text slightly less subjective and
>> slightly less tongue-in-cheek?
> Wow-wee is that refreshing gang, thanks.  I do recognize that I could
> have done more of my own homework here, but: as a neophyte programmer,
> that is endlessly true (of an endless array of topics -- I think
> otherwise known as an "infinite regress"), and it is always nice to find
> something spelled out in a clear, concise manner. Then I can move on
> quickly to the next conundrum, rather than having to investigate some
> vague insinuation at every step, potentially wasting other people's
> time in the process.
>
>> May we have a real name please to credit in the ChangeLog entry?
> I would be "Mark T. Eriksen".
>

Re: Makefile to Makefile.am

[John Calcote]

 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 build your project on systems that support the
>> Autotools, but do not support GNU make (not many these days).
>
> While GNU make may be 'supported' on a wide variety of systems, that
> does not mean that it is the default 'make' program on a system, or
> available on the system by default.  The user may need to do something
> special in order to install and invoke GNU make.
>
> If depending on GNU make was considered ok, then Automake would have
> been developed quite differently than it is.  Given current Automake
> objectives, it is wise that individual projects also try to avoid GNU
> make syntax in Makefile.am.

Excellent point Bob.

John

Re: Makefile to Makefile.am

[John Calcote]

 On 8/14/2010 7:09 PM, samson.pierre wrote:
>
> Yes it works :-)
>
> But I see a little warning when I call autoreconf :
> `%'-style pattern rules are a GNU make extension
>
> I think it is because I use this character ‘%’ in my rules. But this ‘%’ is 
> very interesting to define an implicit rules.
>
> Is there an equivalent or anything else which can help me to write this rule 
> avoiding this warning message?

The use of % in rules is indeed a GNU make extension. This is called a
pattern rule. Pattern rules in GNU make should be used in place of older
style suffix rules which use asterisk (*) to define the stem of a
wildcard pattern. The difference is that pattern rule patterns can
define general file matching patterns (e.g., a%de.o) , whereas suffix
rules can only define patterns that match files with a particular
extension (e.g., *.txt).

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

Re: conditionals in Makefile.am

[John Calcote]

On 6/30/2010 3:41 AM, Wesley Smith wrote:
>> From the automake manual:
>> 
> You may only test a single variable in an if statement, possibly
> negated using ‘!’. The else statement may be omitted. Conditionals may
> be nested to any depth. You may specify an argument to else in which
> case it must be the negation of the condition used for the current if.
> Similarly you may specify the condition that is closed on the endif
> line:
>
>  if DEBUG
>  DBG = debug
>  else !DEBUG
>  DBG =
>  endif !DEBUG
>
>
> What'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

Re: performing pre-build shell commands with automake

[John Calcote]

On 6/20/2010 4:48 PM, Wesley Smith wrote:
>
>> src/lcairo.c : resource.qt
>>
>> I tested this and it works - here's my test code:
>> 
> It definitely does work!  Thanks so much.  The QT resources in my case
> or code generated files from the actual source files, so it makes
> sense to trigger the rules off of the sources themselves.  I really
> appreciate the help.
>   

Don't forget to write proper clean rules to cleanup the generated
sources. And also don't forget to add your generated sources (header
files? - I'm not a QT expert so I'm not sure of the exact nature of your
generated sources) to a nodist__SOURCES variable so that make
dist doesn't distribute them.

To test the clean rules to ensure you've cleaned up everything you
generated, run "make distcheck". This will build and test a distribution
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

Re: performing pre-build shell commands with automake

[John Calcote]

On 6/20/2010 3:05 PM, Wesley Smith wrote:
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../..
> -I/usr/include/lua5.1 -I/usr/include/cairo -I/usr/include/directfb
> -I/usr/include/freetype2 -g -O2 -MT lcairo.lo -MD -MP -MF
> .deps/lcairo.Tpo -c src/lcairo.c  -fPIC -DPIC -o .libs/lcairo.o
>
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../..
> -I/usr/include/lua5.1 -I/usr/include/cairo -I/usr/include/directfb
> -I/usr/include/freetype2 -g -O2 -MT lcairo.lo -MD -MP -MF
> .deps/lcairo.Tpo -c src/lcairo.c -o lcairo.o >/dev/null 2>&1
>   
> There are 2 issues I see:
> 1) Why would the Makefile.am below produce 2 commands compiling the
> same source file into 2 different directories?
>   

The two libtool commands are not exactly alike. The first command
generates position-independent code (PIC) to be used in your libtool
shared library. That's why the object file is placed in the .libs
directory. The second line doesn't use the -fPIC and -DPIC options. This
version of the object file is used in the traditional archive (static
library). The double compile comes from the use of Libtool. However, if
you don't use Libtool, you'll only get static libraries.

> 2) One of those builds commands actually puts lcairo.o in the same
> directory as the Makefile, so I would assume that the rule lcairo.o
> would correspond to this step.
>   

Automake is a little too smart for us here. It won't generate a rule to
build a libtool object if you've already written one - even if it's only
a dependency rule (no commands). To fix this, place the dependency on
the source file, not on the object:

src/lcairo.c : resource.qt

I tested this and it works - here's my test code:

lib_LTLIBRARIES = libfoo.la

libfoo_la_SOURCES = src/foo.c

resource.qt:
touch TESTING

src/foo.c: resource.qt

And here's the result of running make in the Makefile.am directory:

$ make
touch TESTING
/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DPACKAGE_NAME=\"foo\"
-DPACKAGE_TARNAME=\"foo\" -DPACKAGE_VERSION=\"1.0\"
-DPACKAGE_STRING=\"foo\ 1.0\" -DPACKAGE_BUGREPORT=\"\"
-DPACKAGE_URL=\"\" -DPACKAGE=\"foo\" -DVERSION=\"1.0\" -DSTDC_HEADERS=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1
-DLT_OBJDIR=\".libs/\" -I. -g -O2 -MT foo.lo -MD -MP -MF
.deps/foo.Tpo -c -o foo.lo `test -f 'src/foo.c' || echo './'`src/foo.c
libtool: compile:  gcc -DPACKAGE_NAME=\"foo\" -DPACKAGE_TARNAME=\"foo\"
-DPACKAGE_VERSION=\"1.0\" "-DPACKAGE_STRING=\"foo 1.0\""
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"foo\"
-DVERSION=\"1.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1
-DLT_OBJDIR=\".libs/\" -I. -g -O2 -MT foo.lo -MD -MP -MF .deps/foo.Tpo
-c src/foo.c  -fPIC -DPIC -o .libs/foo.o
libtool: compile:  gcc -DPACKAGE_NAME=\"foo\" -DPACKAGE_TARNAME=\"foo\"
-DPACKAGE_VERSION=\"1.0\" "-DPACKAGE_STRING=\"foo 1.0\""
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"foo\"
-DVERSION=\"1.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1
-DLT_OBJDIR=\".libs/\" -I. -g -O2 -MT foo.lo -MD -MP -MF .deps/foo.Tpo
-c src/foo.c -o foo.o >/dev/null 2>&1
mv -f .deps/foo.Tpo .deps/foo.Plo
/bin/sh ../libtool --tag=CC   --mode=link gcc  -g -O2   -o libfoo.la
-rpath /usr/local/lib foo.lo
libtool: link: gcc -shared  .libs/foo.o  -Wl,-soname -Wl,libfoo.so.0
-o .libs/libfoo.so.0.0.0
libtool: link: (cd ".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

Re: performing pre-build shell commands with automake

[John Calcote]

On 6/20/2010 2:34 PM, Wesley Smith wrote:
> I also tried using lcairo.lo, which triggered the preliminary shell
> commands but barfed because the commands didn't generate lcairo.lo.
> hmm..  Is there a way to print out what rules were invoked during a
> make invocation?
>   

You do want the actual object (.o on most platforms) file - the .lo file
is a text file containing libtool meta-information text about the
object. There are some make debugging aids involving dumping the rule
database, but you'll have better luck by carefully analyzing the output
lines during a build - they'll tell you what object files are being
generated from your sources and where they're being put.

John

Re: performing pre-build shell commands with automake

[John Calcote]

Wes,

On 6/20/2010 2:14 PM, Wesley Smith wrote:
> How does one do this kind of thing when the source file is specified
> in a subfolder?
> INCLUDES = -I/usr/include/lua5.1 -I/usr/include/cairo
> -I/usr/include/directfb -I/usr/include/freetype2
>
> lib_LTLIBRARIES = cairo.la
> cairo_la_LDFLAGS = -module -avoid-version
> cairo_la_LIBADD = -llua5.1 -L/usr/lib -lcairo -L/usr/lib -ldirectfb
> -L/usr/lib -lfreetype -L/usr/lib
> cairo_la_SOURCES = src/lcairo.c
>
> resource.qt:
>   touch TESTING
>
> lcairo.o: resource.qt
>
>
>
> lcairo.o never gets triggered here.  If I explicitly do make lcairo.o
> then it will get triggered, but I'm not sure from scanning the
> Makefile and Makefile.in how it would get implicitly triggered.
>   

Build once without your qt dependencies in place and carefully note the
name and relative location of the object file generated from
src/lcairo.c. The qt dependency rule will have to look like this:

exact-name-and-relative-location-of-object : resource.qt

This is the short answer. You might also want to use the $(OBJEXT) macro
for the extension on the object file for portability'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

Re: performing pre-build shell commands with automake

[John Calcote]

Hi Wesley,

You could use BUILT_SOURCES to accomplish this. Any sources listed in
BUILT_SOURCES are built before any other rules are executed. Automake
does this by making BUILT_SOURCES a dependency of "all", "check" and
"install", so that when you run "make all", "make check" or "make
install", the files listed in BUILT_SOURCES are updated first.

However, that said, the correct way to do what you want is to place a
make dependency between the sources you want to generate, and the
consumers of those sources. Automake generates normal makefiles (or
rather makefile.in templates for Autotconf) from Makefile.am files. Some
of the code in a Makefile.am file contain directives for automake. The
rest is just make script that is passed through from Makefile.am to
(ultimately) Makefile.

Just write rules like this:

consumer.o: resource.qt

and resource.qt will get built before consumer.o tries to consume it.
Ultimately, this is the effect of BUILT_SOURCES, but the dependencies
aren't managed as well as they could be with BUILT_SOURCES - your qt
files will only get built if the user types "make all", "make 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, Wesley Smith wrote:
> I've been looking through the automake docs trying to figure out how
> to execute shell commands as part of the build process but before
> anything actually gets compiled.  Is this possible?  I need this for
> things like Qt's 'moc' and some other script-based code generation
> utilities.  thanks in advance!
>
> wes
>
>
>   

Re: nodist_BUILT_SOURCES?

[John Calcote]

Hi Monty,

On 6/10/2010 11:42 AM, Monty Taylor wrote:
> Hey all,
>
> Potentially odd question...
>
> How would I accomplish something like what's in the subject? I have a
> source file that wants to be built before other files - so including it
> in BUILT_SOURCES does the right thing, but I do _not_ want to have it
> included in the dist tarball.
>
>   

Files listed in BUILT_SOURCES are not taken into account wrt
distribution. The distribution list is built from other primary-like
constructs, such as *_SOURCES. The example in the autoconf manual shows
how you would do what you want:

...
nodist_foo_SOURCES = bindir.h
BUILT_SOURCES = bindir.h
...

In this example, BUILT_SOURCES is used only to get bindir.h built up
front. The actual SOURCES variable used to list its use by a particular
product carries the nodist prefix, which keeps it from being distributed.
I tried removing it from BUILT_SOURCES and adding in a rule that looks like:

> %.cc: drizzled/configmake.h
>
> But that didn't work.
>
> Any thoughts?
>
> While we're at it - this whole thing is to get expanded values of
> autoconf directories into a header file where I can consume them...
> which because they contain nested variables
> (localstatedir=${prefix}/var}) I seemingly have to do at make time. The
> dist problem above could be solved if anybody knows a decent trick to
> fully expand those variables at configure time... I've tried many
> combinations of eval and quoting - but nothing seems to do what I'm
> trying to do.
>   

You can't (or rather shouldn't) fully expand these variables at
configure time because they may be modified at make time by the user on
the make command line (e.g., make prefix=xxx). There are two
widely-practiced options:

1. Replace such variables on the compiler command line for all or some
sources:

mylib_la_CPPFLAGS =\
 -DSYSCONFDIR=\"$(sysconfdir)\"\
 -DSYSLOGDIR=\"$(syslogdir)\" ...

This works well for situations where you only have a few variables to
replace.

2. Add some custom rules to your Makefile.am scripts that build your
source files using variable replacement techniques like those used by
Autoconf:

EXTRA_DIST = myprog.cfg.in

edit = sed \
   -e 's|@sysconfd...@]|$(sysconfdir)|g' \
   -e 's|@sysrund...@]|$(sysrundir)|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

Re: Regarding the JAVA primary

[John Calcote]

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, they do. BTW, does anyone know why?

With some sarcasm someone could tell that it is done in this way
because with Java you need to make heaps of files (e.g. one for
every public exception), but maybe it has a good reason?

We use some very old and surely bad custom automake rules to
compile java sources. Ages ago we also had some wildcard (`find')
rules (inspired by ant assuming `this would be the good way to
go'). Those rules collected the files, but we changed them to use
a list of file names, which seemed much cleaner and solved some
issues (which of course could had been solved in other ways,
too).
   


Actually, the only thing bad about the current JAVA primary make rules 
is that the command line length may easily be exceeded with very large 
file sets (in fact, with hundreds of files, it surely will be exceeded 
on some platforms). But this problem can easily be fixed by dumping all 
of the source files into a temporary text file (filename), and then by 
using @filename on the javac command line.



One motivation for this change was that our make rules that
generated the exception source code files (many differing more or
less just in the name and some `String name ...') and people
forgot to add the files, so if existing for them they had been
built but not for others where the files were not updated (and
the new gensrc files were missing). This resulted in an
incomplete jar file and unfortunately when using this jar a
compilation error was flagged out in the wrong package... unit
tests did not helped because of course also missing in the
incomplete jars (and the make check scheme we used also used a
wildcard approach to collect the unit tests to be executed).
Strange things happend when switching between branches (where
typically the number and kind of exceptions changed etc).
   


Yes, Java does promote the use of many source files - not necessarily a 
bad thing, as this could be seen to promote modular design, if used 
correctly and wisely. I tend to use static inner classes to keep 
relevant things together and to reduce the number of source files. The 
nice thing about this approach is that it's generally fairly easy to see 
where a class should be defined at the outer scope (and thus in its own 
source file), or within another class.



I disliked that when by some problem almost all sources would get
lost in a sandbox (e.g. if switching to a bad / incomplete tag),
make (and even make check!) succeeded.

On `tree conflicts' (one changed a file, another moved it) it
could even happen to have two times the same functionality in a
jar...

To build a list of files why not open Makefile.am in $EDITOR,
like vim or emacs, and insert the file list here (in vim, you may
start a line `java_source = \' and on the next blank line use
`!!find . -name "*.java" -exec echo "{}" "\\" ";"'
which works except for the last file, which ends with a `\'.). No
need to make this at make run time, or is there any?

By this, cvs diff (or whichever SCM tool is used) easily shows
the included files which is easier to review I think.

Using wildcards IMHO means to logically `include' the directory
contents to the Makefile. I think you cannot even use it as
dependency (and thus I'd guess the jars would be resigned on each
make run, even if no file changed?).

What is the advantage of using find magic and make time?

How do you handle your java.in files?
How are you safe to get old generated files out the jar (if
removed from gensrc, they still are in builddir and the make
clean rule may not even take it any longer - how to notice?).

I'm afraid the find/wildcard approach only works for simple
builds - but those could also be done by ant I think...
   


All very good points - and all issues that Automake has been designed to 
overcome. Many folks don't like the requirement that all source files 
must be specified statically in Makefile.am. I'm not one of these 
people. I tend to agree with you. For Java, I think it's a matter of 
developer convenience that sources in a tree are specified with a 
globbing pattern. It's not just that there are a lot of files, but also 
that they tend to be spread around the source tree because they belong 
to various packages that are defined by their location within the source 
tree.


I can certainly see how we may want to stick with the Automake "static 
source file specification" rules for the reasons you point out. In this 
case, it becomes more of an evangelistic documentation issue. :) That 
is, we might be wise to add a chapter to the Automake manual describing 

Regarding the JAVA primary

[John Calcote]

Hi Ralf,

I've been thinking a lot about the JAVA primary lately. It turns out 
that Automake's handling of Java sources is pretty efficient. 
Experiments indicate that building ~500 Java source files in a single 
command takes about 15 seconds on a 1.8 GHz CPU with 512 MB RAM. That 
same set of 500 sources, built individually can take upwards of 500 
seconds - a 40 times increase in compile time. (GNU Make, O'Reilly)


In other words, it's simply better to not manage individual 
source/object dependencies in Java. You win the battle, so to speak -- 
but you lose the war.


Since the current implementation of the JAVA primary is not managing 
individual source/object dependencies (something that's difficult to do 
anyway because of inner and anonymous class definitions), would it not 
be prudent to remove the restriction regarding needing to specify all 
source files individually in Makefile.am -- at least for the JAVA primary?


Builds in the Java world generally specify source files found within a 
subtree using a globbing mechanism, with optionally specified inclusions 
and exclusions. And the layout of that subtree defines the packages to 
which classes belong. Would it not be fair to say that all files found 
matching the source specification within a specified subtree are 
distributed within the directory layout to which they belong? In other 
words, distribution (for Java sources only) would include the same set 
of files specified in the Java source globbing pattern. Here's an example:


sources = src/**/*.java
exclude = src/examples/*.java

Distributed Java sources would include everything defined by /sources/. 
Excluded files would be excluded from the build, but not from distribution.


I'm not stealing this concept entirely from ant. Most of the Java IDE's 
(NetBeans, IntelliJ, Eclipse, etc) also use almost the same mechanism 
for specifying sources belonging to a particular build.


I recognize that this is a significant deviation from existing Autotools 
methodology, but I'm not sure we can make any real forward progress in 
Autotools Java builds without making a few such concessions.


A problem I foresee is providing the globbing functionality to makefile 
commands. We'd almost need a new auxiliary script (like install-sh) to 
generate lists of files from such glob specs. Not sure yet from where 
the primary functionality would come -- perhaps a java utility, so that 
the same level of portability would be available to java builds as the 
source that's being built. That is, if someone uses the JAVA primary, 
he/she can expect to be required to have additional build functionality 
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

Re: Keeping source directory structure

[John Calcote]

On 3/24/2010 11:22 AM, Peter Johansson wrote:

Hi Brendon,

Brendon Costa wrote:

So I tried replacing the variable with:
XXX_SOURCES= \
   ../common/map.cpp \
   ../linux/map.cpp

This will kind of build, though the location it is putting the object
files in is really bad and conflicts with those from other makefiles.
I.e. they are going into:
/common/map.o
/linux/map.o
It is not clear what the conflict is here. Are you creating several 
map.o files from the same map.cc? why?


He's using a non-recursive build system that pulls source files of the 
same name from two different 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

Re: Building prog first

[John Calcote]

On 3/22/2010 4:34 PM, Reuben Thomas wrote:

What about using a info browser to search through the manual?
   
I often do that. The trouble is that often what I want to know has to

be deduced from the manual, which is natural enough, because the
manual tends to be structured according to the structure of the
program it documents, rather than of the problems the user is trying
to solve. By using web searches I can often find people asking and
answering precisely the problem I'm trying to solve.
   


Reuben, you've just hit upon one of the two most significant problems 
with Javadoc and the like (including doxygen, man pages, and info pages):


1. You have to already know the API to know where to look for help on 
the API because the documentation is structured according to the API, 
rather than according to the top 100 use cases.


2. Most people don't add more than 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

Re: Building prog first

[John Calcote]

Hi Russell,

On 3/21/2010 6:14 AM, Russell Shaw wrote:

I was limping along for years learning autoconf/make in bits until this
tutorial came out

  Autotools: a practitioner's guide to Autoconf, Automake and Libtool

http://www.freesoftwaremagazine.com/books/autotools_a_guide_to_autoconf_automake_libtool 



I realized a lot of useful things after that. The main thing that makes
it easy is that a real project is stepped through with lots of side 
discussions,
and high-level overviews put things in to perspective. I'd really like 
to have

a hard-copy book of that tutorial.


Thanks 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 understand the autoconf manual. I was on dos/windows
up to nearly yr2000 or so, so i had to learn unix programming, shell
programming, make-file programming, m4, how unix processes work etc,
to be able to look in generated Makefiles and "configure" and see from
that what errors i was making in configure.ac and automake.am.
Learning too many things simultaneously, but i know now.

Re: Baked-in paths

[John Calcote]

Hi Reuben,

On 3/14/2010 4:29 PM, Reuben Thomas wrote:

I imagine this question has been asked before, but searching the
archives, the net and the manual didn't help me with the following:

I have a C program which loads some scripts at runtime. These are
stored in datadir (e.g. /usr/local/share/prog). But I also want to be
able to run the program from its build directory.

At the moment I bake in the relevant path; I imagine that for "make
install" I have to rebuild the binary, baking in the installation
path, having baked the build directory path in a normal "make".

Is there a recommended way to deal with this situation?

   


The software packages I've worked on have all been complex enough to 
warrant a configuration file in the system config directory (/etc, 
whatever), which is locked down by virtue of its location. Since only 
the administrator can change the contents of a file in $(sysconfdir), 
it's not a security issue.


But what this does allow me to do is generate an installed configuration 
file with reasonable default paths derived from $(prefix) variables. At 
the same time, I bake default paths into the application, which are also 
derived from $(prefix) variables and passed on the compiler command 
line. This allows me to run without a config file, as long as the app is 
properly installed. Finally, the key benefit is that I can run my 
program in test mode by supplying an appropriate config file on the 
command line (./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

Re: Public header files

[John Calcote]

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 venture: "long long long"? And please don't say we'll never have
128-bit systems. We've been down that road before; we know where it
leads.
 

Usually by the time one gets to the point of standardizing something, it's
both too late to fix the aesthetics and aesthetics are the least of
anyone's concerns.  A lot of things that make it into standards are
widespread existing practice before then, and it's too much work to change
them.

I suspect this is part of why, as you point out, the standard also
introduces int_t at the same time, but "long long" is more widely
supported, probably because it's older than the standard.
   


Of course you're right Russ.

John

Re: Public header files

[John Calcote]

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 guaranteed to be present. So I just want to make
sure it will work on other systems too.

"long long" has been standard for 11 years now.  It is irritating
that some vendors have apparently not updated their C compilers
in that long.


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 venture: "long long long"? And please don't say we'll 
never have 128-bit systems. We've been down that road before; we know 
where it leads.


Personally, I like the idea of using int64_t and uint64_t. The exact 
same standard already defines such types for the more commonly used 
sizes, and it is scalable.


John

Re: Public header files

[John Calcote]

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 guaranteed to be present. So I just want to make
sure it will work on other systems too.
 

"long long" has been standard for 11 years now.  It is irritating
that some vendors have apparently not updated their C compilers
in that long.
   


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 venture: "long long long"? And please don't say we'll never have 
128-bit systems. We've been down that road before; we know where it leads.


Personally, I like the idea of using int64_t and uint64_t. The exact 
same standard already defines such types for the more commonly used 
sizes, and it is scalable.


John

Re: cross-compiling on 64 to 32-bit Linuxlocalhost/

[John Calcote]

Hi Gregory,

On 3/2/2010 4:14 PM, Grégory Pakosz wrote:

  ./configure --host=i686-pc-linux-gnu \
   --prefix=/arch/x86-linux/gnu \
   CC="gcc -m32 -march=i586" \
   CXX="g++ -m32 -march=i586" \
   LDFLAGS="-m32"
 

I'm curious about why setting "--host=i686-pc-linux-gnu" is not enough
to achieve cross compiling and why in that case it's not up to
autoconf to add "-m32" to CC.
   


You don't need to specify -m32 if you have a tool set prefixed with the 
cross tag. The reason for using -m32 is because the user wants to use 
his 64-bit gcc to compile 32-bit code, so he has to tell the compiler to 
switch to 32-bit mode also. (Incidentally, if you're running on Linux, 
might also be a good idea to tell the compiler you're running in a 
32-bit environment by 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

Re: split check target into check and test targets

[John Calcote]

On 2/24/2010 1:50 AM, Baurzhan Ismagulov wrote:

On Tue, Feb 23, 2010 at 04:05:47PM -0800, Daily, Jeff A wrote:
   

I attempted to split the "make check" target into "make check" (build
check_PROGRAMS) and "make test" (run check_PROGRAMS). However, I get
warnings that check-am was overridden. How might I split the building
and running of check_PROGRAMS and still use the generated
parallel-tests using TESTS? Thanks.
 

There are also these ways:
http://www.opensubscriber.com/message/automake@gnu.org/2136673.html
   


Additionally, if I want to build a particular 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

Re: Creating a partial library

[John Calcote]

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 shared library. My
example has a couple of minor flaws that I realized last night after
sending it, including the missing uninstall-local rule:

install-exec-local:
 libtool --mode=install ./install-sh -c libhello.a 
$(DESTDIR)$(libdir)/libhello.a

uninstall-local:
rm -f $(DESTDIR)$(libdir)/libhello.a
 

If you are using Automake (and on this list, I guess that's pretty much
given), then please use the variables to pick up the in-tree libtool
script as well as the usual flag variables for the makefile.am author
and the user:
   


Thanks for cleaning it up for me. And the tip about adding custom rules 
as dependencies of the standard rule is priceless.


:)

John

Re: Creating a partial library

[John Calcote]

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 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).
 

ohh this is interesting. Isn't this breaking `make uninstall' and
thus `make distcheck'?  Would it be possible (better/suited/correct)
to have some lib_LIBRARIES=libother.a with a custom build rule
that simply copies the file? Then make install/uninstall could
work, but maybe this breaks other things?
   


The trouble with LIBRARIES is that it only builds non-PIC static 
libraries, which can't be linked into a libtool shared library. My 
example has a couple of minor flaws that I realized last night after 
sending it, including the missing uninstall-local rule:


install-exec-local:
libtool --mode=install ./install-sh -c libhello.a 
$(DESTDIR)$(libdir)/libhello.a

uninstall-local:
rm -f $(DESTDIR)$(libdir)/libhello.a

John

Re: Creating a partial library

[John Calcote]

Hi Justin,

On 2/2/2010 6:39 PM, Justin Seyster wrote:


I'm pretty sure that making the framework a convenience library is my
ideal solution: the plug-in author will be able to distribute a single
shared object without any non-standard dependencies.  However, I read
that Automake does not allow installing a convenience library.  I
verified that a regular static library (not specified with
noinst_LTLIBRARIES) definitely does not work: the resulting .a file is
not position independent and won't link into a plug-in.  I don't want
to use noinst_LTLIBRARIES, though, for the simple reason that I want
to be able to install the library!
   


A convenience library is so named because it provides the convenient 
effect of encapsulating a set of code that multiple products can link to 
within a package. That's it's only purpose - to bundle up code that can 
then be linked into multiple products within your package. Hence, it's 
not intended to be consumed outside of your package.


You're correct in understanding that a non-libtool (*_LIBRARY) product 
is a non-PIC static library, and you are also correct in understanding 
that they can't be linked into a shared library for this reason.


You can build installed LTLIBRARIES as shared libraries, static 
libraries, or both, and you can configure the default in your 
configure.ac file, but unfortunately, I haven't found a way to make this 
default apply only to a subset of the installed LTLIBRARIES built within 
a package. It appears to be all or nothing. Furthermore, it's just a 
default. The user can always override your defaults with command line 
options to configure. Personally, I think it would be a nice enhancement 
to Automake to allow you to specify that you want specifically to build 
an installed static (only) LTLIBRARY that can then be linked into a 
shared library in another package. The Libtool manual states that 
there's no good reason for doing this, but you and I have both 
encountered situations when we want to do just this.


For the reasons outlined above, automake doesn't allow you to build a 
convenience library and install it. The only way to build a convenience 
(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 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

Re: silent installs

[John Calcote]

On 1/29/2010 10:17 AM, Steffen Dettmer wrote:

On Fri, Jan 29, 2010 at 5:21 PM, Bob Friesenhahn
  wrote:
   

Regarding silent installs: Why do passenger trains have windows?
 

Why do passenger train windows have curtains?
SCNR :)
   


Okay - I can't help it! I bet the engineer's windows don't have curtains.

John

Re: Asking for a tutorial to solve two different cases

[John Calcote]

Hi Glus,

On 10/15/2009 9:41 AM, Glus wrote:

I'm developping an application. The question is that once installed I'd like
to find it hanged to my Gnome general applications menu. For this, I'm
searching the info about how should I configure the autotools files project.

I'd like to take the opportunity to ask you also the same but in the case of
a server. How should I do to update /etc/services, /etc/rc.Xd/, to transfer
permissions...   ???
   


Neither of these situations is handled directly by either Autoconf or 
Automake. These are really very much OS- and desktop-specific issues. 
You'll have to research various other forums to find out more about them.


I suggest looking at the Gnome desktop forums at 
http://gnomesupport.org/forums to ask about what sorts of files need to 
be installed and where in order to add menu items and links.


While it's true that installing daemons and server software is more a 
general Unix topic, the way these types of services are installed and 
manipulated is very different from one Unix to another. Linux has only 
recently standardized some aspects of this activity. For installing 
Linux services, you might check with linuxforums.org, or forums 
associated with your particular flavor of Linux (Ubuntu, Suse, Redhat, 
Gentoo, Slackware, Debian, etc. All of these have developer forums of 
their own).


Once you have the specific information on what files to install where, 
then you can write hand-coded 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

Re: Difficulty cross-compiling

[John Calcote]

Hi William,

On 10/12/2009 12:26 PM, William Tracy (wtracy) wrote:

I'm trying to cross-compile a library that uses GNU Autotools (Google
Coredumper, to be specific) for PPC using the MontaVista tool chain. The
sequence of commands I'm following is:

$ ./configure --host=ppc CC=/path/to/gcc CXX=/path/to/g++

$ make

$ [next step would normally be "make install"]

For a normal (not cross-compile) configuration, issuing "make" causes a
.libs/ directory to be generating containing .a, .o, and .so files (and
variants thereof). When I cross-compile for PPC, the directory is
created and populated with a .a file, but no .so files. I can see .o and
.lo files being generated, so the code *is* getting compiled, but the
linking stage gets skipped. When I review the make output, there are no
error messages or warnings-the commands related to the .so files are
simply missing.
   


You don't state your target OS, only the CPU architecture, and I'm not 
familiar with MontaVista, so I'm not sure I'm helping here. But if your 
target platform is AIX, or anything like it, you may be experiencing 
AIX-library-naming-difference syndrome - a sense of disorientation 
associated with not being able to find your AIX shared libraries after 
building. ;-)


The default library extension for some versions of AIX is .a. These .a 
files contain the equivalent of standard Unix static /and dynamic/ 
libraries. Thus, on AIX/PPC, .a files are dynamically 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

Re: "make dist" and "make distcheck" trouble

[John Calcote]

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. ;)

Re: "make dist" and "make distcheck" trouble

[John Calcote]

Bruce,

On 9/28/2009 7:03 PM, David Bruce wrote:

Hello Ralf,

I found it!  It was an utterly perversely subtle typographical error:

In my src/Makefile.am:

tuxmathserver_SOURCES = servermain.c\
server.c \
mathcards.c \
throttle.c  \
.   options.c

^
|
|


A stray '.' got inserted in the file list, which lead to the entire
   


Dang! I'm sorry. I noticed that period, but a period is so small that I 
almost thought it was dust on my monitor! Then I looked a second time 
and realized 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

Re: Dependency issues after adding new sources.

[John Calcote]

Hi Dave,

On 9/11/2009 9:24 AM, Dave Steenburgh wrote:

Please excuse my ignorance, but my search fu is weak, and I think the
authors of tfm are conspiring to bewilder me.  I have read several tutorials
and discussions on how to use the autotools, but to be honest my
understanding of them is extremely limited at best.
I have this problem with several of my programs, but it's most frustrating
with my current program, which at the moment has a flat directory structure.
  The program in question is developed little by little, so from time to time
I need to add new source files to the program's _SOURCES in Makefile.am.  I
was under the impression that after doing so, running make from the build
directory would magically figure everything out and build the program
correctly.  What happens instead is the Makefile appears to be regenerated,
but my new sources are not included in it.  I have tried multiple methods to
fix this, most of them to no avail.  Currently, the new sources are built
and are linked into the executable, but most of the old sources aren't being
rebuilt when a common header is changed.  The only thing that fixes all the
issues is to start with an empty build directory and re-run the configure
script.  I doubt that it's really necessary to create a new build directory
every time I add a new class.  So what could I be doing wrong?  I will
gladly share any information about my build environment that may help a
diagnosis, but I'd prefer 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

Re: installing glade3 interface file with autotools

[John Calcote]

Hi Mick,

Your Automake syntax is correct, if you're trying to install a 
pre-existing data file called nuchimp.xml into the /usr/local/share 
(default $(datadir)) directory. The error you're getting indicates that 
make can't fine the file nuchimp.xml. Are you sure it exists 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 nightmare trying to get the
XML file created from glade by:
gtk-builder-convert nuchimp.glade nuchimp.xml

After reading various documents I have the following Makefile.am:
bin_PROGRAMS = nuchimp

nuchimp_SOURCES = \
callback.c callback.h \
chimp.c chimp.h \
main.c main.h \
parsecfg.c parsecfg.h

xmldir = $(datadir)
xml_DATA = nuchimp.xml

AM_CPPFLAGS = $(GTK_CFLAGS)
AM_LDFLAGS = $(GTK_LIBS) -export-dynamic

the clearest doc stated the two lines beginning xml would do exactly
what I need but I make, I get:
make[2]: *** No rule to make target `nuchimp.xml', needed by `all-am'.
Stop.

this is doing my head in so PLEASE, someone wiser than me, point me to a
clear explanation of the process.


___
Autoconf mailing list
autoc...@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

   

Re: simple 'install of png file' question

[John Calcote]

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

Re: simple 'install of png file' question

[John Calcote]

Hi David,

On 8/11/2009 7:28 AM, David Liebman wrote:

Hello,

This is a newbie question.

I have a simple project that I'm using automake and autoconf on. It
involves a simple c program, but uses a png image. The png image is in a
directory called 'pics' and I want it copied to a certain directory on
the system when the user calls the 'install' target.

I suspect the proper thing to do is to make a Makefile in the 'pics'
directory and have that makefile install the png. How do I go about
doing that? Does anyone have a link to a good example of how this is
done? If I am creating a Makefile in the pics directory I would like the
Makefile to be auto-generated.
   


You may create a new Makefile.am file in the pics directory if you wish, 
or you don't have to. Here's how to do this if you don't create a new 
Makefile.am. Add this code to the parent directory's Makefile.am:


picdir = $(datadir)/pics # assuming you want png's installed in 
/usr/local/share/pics

pic_DATA = mypicture.png

That's it! Regarding the location where you want to install - try to use 
standard places if you can, but if you can't then try to build on 
standard places defined in the automake provided environment variables.


Regards,
John

Re: library dependencies SUBDIR problem automake

[John Calcote]

Hi Michiel,

On 8/4/2009 10:01 AM, Michiel Soede wrote:

Hi,
I have a problem with dependencies to libraries in my build structure.the 
directory structure in my project is as follows (roughly):

configure.acmakefile.amapps/ makefile.am app1/   
main.cc   makefile.am   comps/ makefile.am 
comp1/   comp1.cc   makefile.am
the component makefile generates a library:noinst_LIBRARIES = 
libcomp1.alibcomp1a_a_SOURCES = comp1.cc
I recurse in all subdirectories, using SUBDIRS:SUBDIRS = apps comps
in the comps:SUBDIRS = comp1
same for the apps directory.
the app1 uses LDADD to link the app with main.cc
bin_PROGRAMS = app1app1_SOURCES = main.ccapp1_LDADD = 
$(top_builddir)/comps/comp1/libcomp1.a
Now when I call make at the root, everything is build correctly.
But when I cd into apps/app1/ and call make, I have problems with:
- if comp1 was not made before (e.g. from the root), make will fail  (no rule 
to make libcomp1.a)
- if I did make the library at the root, it is not recompiled automatically 
when  I modify comp1.cc
.. any ideas on these problems?
   
The lack of proper text wrapping on your message made it a bit difficult 
to see your directory structure, but I think I've sorted it out, based 
on your other comments:


configure.ac
makefile.am
apps/
  makefile.am
  app1/
main.cc
makefile.am
comps/
  makefile.am
  comp1/
comp1.cc
makefile.am

According to your makefiles, app1 is dependent on comp1 (app1_LDADD = 
.../libcomp1.a), but comp1 is not built as a sub-component 
(sub-directory) of app1. Thus, (I believe you are saying) when you build 
from the project root, everything is fine, but when you build from the 
app1 directory, comp1 doesn't get built, and thus the app1 build fails. 
Is this correct?


A recursive build system must be designed to build component 
dependencies first before building the components. Thus, one limitation 
of a recursive build system is that it rather defines (or at least 
constrains) the directory structure that you must use. To get comps to 
be built before apps from within the app1 directory, you must build the 
comps directory structure from within the app1 directory.


I recognize that applications 2-n may also use components 1-n, so you 
have a problem here, and the only way around it is to use a 
non-recursive build system. That is, you can place all of your build 
logic in the top-level Makefile.am file using relative paths, and then 
the makefile dependencies will be properly structured for you by Automake:


Makefile.am:
= = = = = = = = = = =
bin_PROGRAMS = app1 app2 app3 ...
app1_SOURCES = apps/app1/main.cc
app2_SOURCES = apps/app2/...
...

noinst_LIBRARIES = libcomp1.a libcomp2.a libcomp3.a ...
libcomp1_a_SOURCES = comps/comp1/comp1.cc
libcomp2_a_SOURCES = comps/comp2/...
...

app1_LDADD = libcomp1.a
= = = = = = = = = = =

I also noted that you had

SUBDIRS = apps comps

in your top-level Makefile.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

Re: EXTRA_DIST respects Automake conditionals?

[John Calcote]

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:

I was surprised today to discover that EXTRA_DIST respects
Automake conditionals.

In other words, if I have the following Makefile.am:

 AUTOMAKE_OPTIONS = foreign

 EXTRA_DIST =

 if COND
 bin_PROGRAMS = foo
 foo_SOURCES = foo.c
 EXTRA_DIST += EXTRA
 endif

and configure.ac:

 AC_INIT([mumble], [1.0])
 AC_CONFIG_SRCDIR([foo.c])
 AC_CONFIG_FILES([Makefile])
 AM_INIT_AUTOMAKE
 AC_PROG_CC
 AM_CONDITIONAL([COND], [false])
 AC_OUTPUT

then "make dist" will not put EXTRA into the generated tarball.
It will put foo.c into the tarball, though.

Is there an appropriate target to put files that should always be
distributed, regardless of conditionals?  noinst_HEADERS works,
but to me it feels like abuse to use it for this purpose.

For what it's worth, in the actual project where I encountered
this, the usage is more like this:

 if ENABLE_USERSPACE
 ...
 include lib/automake.mk
 include ofproto/automake.mk
 include utilities/automake.mk
 include tests/automake.mk
 include include/automake.mk
 include third-party/automake.mk
 include debian/automake.mk
 include vswitchd/automake.mk
 include xenserver/automake.mk
 if HAVE_CURSES
 if HAVE_PCRE
 include extras/ezio/automake.mk
 endif
 endif
 endif

In other words, I'm using a conditional to disable a great many
features, and it's convenient not to push that conditional down
into all the included files.

Here's the Makefile.am in question:
http://openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=blob;f=Makefile.am;h=dccb8cfdf92a3dd4dc9f3276e7533f68769587f8;hb=c2b070214097fa40dc78252882d96babe7fab4b4

Thanks,

Ben.
   

Re: 答复: how to install library in a s pecific directory?

[John Calcote]

On 7/24/2009 12:36 AM, A117 wrote:

I’ve removed the backslashes and made them all one-line statements. No help.
   


What about the backslash at the end of your commented EXTRA_DIST line? 
Try removing that one too. It could be that it's causing the comment to 
include the following line, 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 = libezcommon.la
myincludedir = $(includedir)/ezproject
myinclude_HEADERS= ezcommon.h tinystr.h tinyxml.h
libezcommon_la_SOURCES = ezcommon.cpp \
tinystr.cpp tinyxml.cpp tinyxmlerror.cpp tinyxmlparser.cpp
#libezcommon_la_LIBADD = tinystr.o tinyxml.o tinyxmlerror.o tinyxmlparser.o
libezcommon_la_LDFLAGS = -version-info 2:0:0
#EXTRA_DIST = tinystr.cpp tinyxml.cpp tinyxmlerror.cpp tinyxmlparser.cpp \
EXTRA_DIST = ezcommon.rc dllmain.cpp ezcommon.aps ezcommon.vcproj icon.ico \
tinyxml.txt resource.h stdafx.h targetver.h


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 files in EXTRA_DIST are to be packed into release 
package. All the cpp files mentioned here already exists and are to be compiled 
and released.
If I put all cpp files in _SOURCES, the EXTRA_DIST files are not released. The 
only way I've found is to put only one cpp file in _SOURCES, while others to 
EXTRA_DIST and add .o to _LIBADD. My goal is to build all the .cpp and put all 
.cpp, .txt, .rc into release package.



Okay, I understand the problem now. But there's not enough information
in the snippet you 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


-
And can I ask another question? I want to build some source code files into 
this library and need to distribute some other files, too. But EXTRA_DIST in 
Makefile.am does not work as below,
lib_LTLIBRARIES = libezcommon.la
...
libezcommon_la_SOURCES = ezcommon.cpp tinystr.cpp ...
EXTRA_DIST = tinyxml.txt ezcommon.rc ...

If I write only one file in libezcommon_la_SOURCES, while adding others to 
EXTRA_DIST and others' .o to libezcommon_la_LIBADD, it works. I don't know why.











   

Re: how to install library in a specific directory?

[John Calcote]

On 7/24/2009 12:21 AM, A117 wrote:

lib_LTLIBRARIES = libezcommon.la
myincludedir = $(includedir)/ezproject
myinclude_HEADERS= ezcommon.h tinystr.h tinyxml.h
libezcommon_la_SOURCES = ezcommon.cpp \
tinystr.cpp tinyxml.cpp tinyxmlerror.cpp tinyxmlparser.cpp
#libezcommon_la_LIBADD = tinystr.o tinyxml.o tinyxmlerror.o tinyxmlparser.o
libezcommon_la_LDFLAGS = -version-info 2:0:0
#EXTRA_DIST = tinystr.cpp tinyxml.cpp tinyxmlerror.cpp tinyxmlparser.cpp \
EXTRA_DIST = ezcommon.rc dllmain.cpp ezcommon.aps ezcommon.vcproj icon.ico \
tinyxml.txt resource.h stdafx.h targetver.h
   


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 files in EXTRA_DIST are to be packed into release 
package. All the cpp files mentioned here already exists and are to be compiled 
and released.
If I put all cpp files in _SOURCES, the EXTRA_DIST files are not released. The 
only way I've found is to put only one cpp file in _SOURCES, while others to 
EXTRA_DIST and add .o to _LIBADD. My goal is to build all the .cpp and put all 
.cpp, .txt, .rc into release package.

 


Okay, I understand the problem now. But there's not enough information
in the snippet you 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

   

-
And can I ask another question? I want to build some source code files into 
this library and need to distribute some other files, too. But EXTRA_DIST in 
Makefile.am does not work as below,
lib_LTLIBRARIES = libezcommon.la
...
libezcommon_la_SOURCES = ezcommon.cpp tinystr.cpp ...
EXTRA_DIST = tinyxml.txt ezcommon.rc ...

If I write only one file in libezcommon_la_SOURCES, while adding others to 
EXTRA_DIST and others' .o to libezcommon_la_LIBADD, it works. I don't know why.


 




   

Re: 答复: how to install library in a s pecific directory?

[John Calcote]

On 7/23/2009 7:45 PM, A117 wrote:

Sorry I forgot to mention the files in EXTRA_DIST are to be packed into release 
package. All the cpp files mentioned here already exists and are to be compiled 
and released.
If I put all cpp files in _SOURCES, the EXTRA_DIST files are not released. The 
only way I've found is to put only one cpp file in _SOURCES, while others to 
EXTRA_DIST and add .o to _LIBADD. My goal is to build all the .cpp and put all 
.cpp, .txt, .rc into release package.
   


Okay, I understand the problem now. But there's not enough information 
in the snippet you 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


-
And can I ask another question? I want to build some source code files into 
this library and need to distribute some other files, too. But EXTRA_DIST in 
Makefile.am does not work as below,
lib_LTLIBRARIES = libezcommon.la
...
libezcommon_la_SOURCES = ezcommon.cpp tinystr.cpp ...
EXTRA_DIST = tinyxml.txt ezcommon.rc ...

If I write only one file in libezcommon_la_SOURCES, while adding others to 
EXTRA_DIST and others' .o to libezcommon_la_LIBADD, it works. I don't know why.

   

Re: how to install library in a specific directory?

[John Calcote]

On 7/23/2009 4:28 AM, A117 wrote:

Why don't I need to run ldconfig manually after installing other official softwares, like osip2? I 
tried "ldconfig -p" and saw the library was aware of, i.e., listed, before running 
"ldconfig". But linkage could not find the library then.
   


Linux distro installers execute ldconfig for you. If you look carefully, 
you'll see that the last stage of installing software (either new or 
updated) is to run ldconfig. On my Opensuse 11.1 Linux installation, 
when I install new software packages from within YaST, I can see 
ldconfig's output just before the installation process completes. If you 
use RPM manually, you may have to run ldconfig yourself after installing 
packages in order to pick up the changes immediately.



And can I ask another question? I want to build some source code files into 
this library and need to distribute some other files, too. But EXTRA_DIST in 
Makefile.am does not work as below,
lib_LTLIBRARIES = libezcommon.la
...
libezcommon_la_SOURCES = ezcommon.cpp tinystr.cpp ...
EXTRA_DIST = tinyxml.txt ezcommon.rc ...

If I write only one file in libezcommon_la_SOURCES, while adding others to 
EXTRA_DIST and others' .o to libezcommon_la_LIBADD, it works. I don't know why.
   


I'm  sorry, I don't understand the question. Are you trying to generate 
sources, or optional build some sources? Perhaps a bit more context on 
the problem...



Thanks for your patience.

- -
   

On 7/22/2009 9:15 PM, A117 wrote:
 

Thank you. I've decided to put the library in /usr/local/lib, while its header 
files in /usr/local/include/ezproject.
It's strange though /usr/local/lib is in /etc/ld.so.conf (actually in another 
file it includes), and I can build other programs acting much as mine, I have 
difficulty with mine only. I run ldconfig manually and then it works. Now I'm 
releasing my software.

   

ldconfig updates the library cache. the /etc/ld.so.conf file is the file
used by ldconfig to determine which directories to scan for libraries.
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
 




   

Re: how to install library in a specific directory?

[John Calcote]

On 7/22/2009 9:15 PM, A117 wrote:

Thank you. I've decided to put the library in /usr/local/lib, while its header 
files in /usr/local/include/ezproject.
It's strange though /usr/local/lib is in /etc/ld.so.conf (actually in another 
file it includes), and I can build other programs acting much as mine, I have 
difficulty with mine only. I run ldconfig manually and then it works. Now I'm 
releasing my software.
   


ldconfig updates the library cache. the /etc/ld.so.conf file is the file 
used by ldconfig to determine which directories to scan for libraries. 
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

Re: how to install library in a specific directory?

[John Calcote]

On 7/22/2009 2:12 AM, bonami wrote:

   I have two projects. One generates a shared library and the other uses it.
The library is to be installed in /usr/local/lib/ezproject, while the
project's name is ezcommon. I have problems in both the projects.
   ezcommon's configure.ac,
…
AC_INIT(ezcommon, 3.0)
AC_DISABLE_STATIC
…
   ezcommon's Makefile.am,
lib_LTLIBRARIES = libezcommon.la
libdir = $(exec_prefix)/lib/ezproject
includedir = $(prefix)/include/ezproject
   Problem is, if user configure --libdir=..., the user's definition will be
ignored. How can I set libdir only when user does not assign it? (Since this
dir name is not same as project name, I cannot use pkglib_.)
   


mylibdir = $(libdir)/ezproject
mylib_LTLIBRARIES=libezcommon.la

myincludedir = $(includedir)/ezproject
myinclude_HEADERS = ...


   The other question is how to check for this library in the other project,
named ezcmd.
   ezcmd's configure.ac,
...
AC_CHECK_LIB([ezcommon], main,,AC_MSG_ERROR(...))
...
   This check will fail, since ezcommon is installed in /usr/local/lib/
ezproject by default. Should I add LDFLAGS=-Lezproject or sth.? And how? Or
should I add this directory to system's link-search directory?
   


If you put your libraries in a non-standard location, then you'll have 
to add that location to the library search path in one way or another. 
Either of the options you mention will work. One other option is to 
generate and install a pkgconfig description file, then use pkgconfig to 
locate the library.


Regards,
John

Re: docdir with "packages" directory

[John Calcote]

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,
therefore, one of the many FS layouts over other (except automake's
own POV) ?

Please understand, LSB-based FS layout is non-common (the same as LSB
itself) even in the Linux world.  Why do you expect that LSB will be
followed somewhere outside?  (Please, remember that Automake works in
more environments that just a Linux, even in all Linux flavors and
distros).
   

Hi Andrew,

Yes, you are correct. I have already answered previous responses to my 
original message. As it turns out, LSB doesn't even specify a particular 
docdir layout. The proper specification comes from the File System 
Hierarchy standard. FSH states that package directories go directly into 
/usr/share/doc, which is exactly as Automake does it.


My particular issue was specific to SuSE Linux - for some reason, they 
chose to place package directories within a "packages" directory beneath 
the proper docdir. I just didn't realize that this was specific to SuSE 
Linux. Live and learn.


Thanks for the feedback.

Regards,
John

Re: docdir with "packages" directory

[John Calcote]

Hi Russ,

On 7/10/2009 12:32 PM, Russ Allbery wrote:

While messing around building RPM files recently, I happened to notice
that most Linux distros like to put documentation files into
${datarootdir}/doc/*packages*/${PACKAGE}.
 


Debian doesn't.
   


My mistake here - sometimes I leap before I look. It appears that some 
RPM-based distros use /usr/share/doc/${PACKAGE} and some use 
/usr/share/doc/${PACKAGE}-${VERSION}. Opensuse uses 
/usr/share/doc/packages/${PACKAGE}, but since I've started researching, 
I've not found any references to other Linux distros that use this.


Sorry for the confusion...

John

docdir with "packages" directory

[John Calcote]

Hi all,

Just a quick question for those who might know.

I understand that Automake generates ${docdir} as 
${datarootdir}/doc/${PACKAGE}, as per the Automake manual, section 2.2.3.


While messing around building RPM files recently, I happened to notice 
that most Linux distros like to put documentation files into 
${datarootdir}/doc/*packages*/${PACKAGE}.


Now, I realize that you can modify the ${docdir} on both the configure 
and make command lines so that it contains the correct values for 
building a proper RPM. But I have a couple of questions:


1) Why the controversy?

2) Is there any movement within the Automake community to move toward 
the LSB directory structure as the default?


Thanks in advance,
John

Re: subdirs that should not be configured

[John Calcote]

Hi Nicolas,

On 7/9/2009 11:13 AM, Nicolas Bock wrote:

Hello list,

I have the following problem: I want to add an external package to our
own package. The external package is already configured in the sense
that its maintainer ran "make dist" and I simply untared the tar file
into some directory underneath our source tree. I add that directory to
AC_CONFIG_SUBDIRS in our main configure.ac and to SUBDIRS in our main
Makefile.am so that when I run our configure script I will also run the
configure script of the source package. The problem I have now is that
when I run autoreconf it descends into the external package and tries to
remake the configure script in there. How can I avoid that from
happening?
   


You can use the autoreconf --no-recursive option. This will autoreconf 
only the current directory. If you have sub-projects that need to be 
recursed into, but you need to skip this one directory, then you can 
create a simple shell script that contains simply:


autoreconf --no-recursive . subdir1 subdir2...

Then, run this shell script to autoreconf only the subdirectories you want.

The real problem here is a mixture of paradigms. You want to treat some 
directories (your own) as maintainer code, and other directories (your 
third-party directories) as user code.


Regards,
John

Re: -I. in DEFAULT_INCLUDES

[John Calcote]

Hi Bob,

On 7/6/2009 5:24 AM, Bob Ham wrote:

Hi there,

I have a problem due to conflicts between local and system header
filenames.  This problem comes about because of the addition of -I. to
the CXXFLAGS of any objects.  I've traced this to a variable called
DEFAULT_INCLUDES in every Makefile.in:

   DEFAULT_INCLUDES = -...@am__isrc@ -I$(top_builddir)


Why does this -I. exist?  How can I remove it?
   


DEFAULT_INCLUDES actually resolves to:

DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)

That is, the current directory, the source directory (if building 
outside the source tree), and the top build directory (in order to pick 
up config.h or other project-global headers.


It is assumed that there would be no header files in the current or 
source directory that are not *more* important (and should thus be 
picked up first) than any other header files outside the project.


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

Re: problems with recursive make target

[John Calcote]

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 wrongly placed cd 
../ didn't work (which I thought was rightly placed) I thought maybe 
that the example code at 
http://www.freesoftwaremagazine.com/books/agaal/catalog_of_reusable_solutions 
was correct and make would handle the cd'ing for me. Maybe I should 
file a documentation bug report with John Calcote!

Fixed! Thanks!

John

Re: problems with recursive make target

[John Calcote]

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 $(SUBDIRS); do \
cd $$dir&&  $(MAKE) $(AM_MAKEFLAGS) $@ || exit 1; \
done
echo `pwd`;
.PHONY : tests
 


You don't ever 'cd' back out of the first subdirectory, so you can't
find the second:
   
Ralf is correct, of course. In my online catalog of solutions, I'd 
copied and modified this code from an Automake-generated Makefile. But I 
inadvertently left the parentheses off the cd command line, which would 
have invoked the entire line in a sub-shell:


for dir in $(SUBDIRS); do \
  (cd $$dir&&  $(MAKE) $(AM_MAKEFLAGS) $@ || exit 1) \
done


Sorry for the confusion.

John

Re: dvi bug in distcheck target?

[John Calcote]

Hi Ralf,

On 6/24/2009 12:59 PM, Ralf Wildenhues wrote:

It looks like the last line should contain:

   zardoz.dvi zardoz.pdf zardoz.ps zardoz.html
 


It would if you had
   @setfilename zardoz.info

in your zardoz.texi file.  Hmm, this is probably a bug in Automake,
but from 'info texi2dvi', I cannot even infer whether it is intentional
that @setfilename not decide the name of DVI or PDF output, and while I
think it implies to do so for HTML, I'm not fully sure either.
Wow. Sure enough. I set the texi setfilename field to zardoz.info and 
all is well again. It 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

dvi bug in distcheck target?

[John Calcote]

Hi Automake maintainers,

I think there's a bug in the distcheck target related to the TEXINFO 
primary. (You may already know about it. I did a google search, but 
didn't find any references to it.)


Here's part of a sample Makefile.am from page 24 of the the Automake 
manual (1.10.2):


bin_PROGRAMS = zardoz
zardoz_SOURCES = main.c
info_TEXINFOS = zardoz.texi

Combined with a simple configure.ac file, when I run "make distcheck", I 
get the following error:


...
ERROR: files left in build directory after distclean:
./zardoz.dvi
make[1]: *** [distcleancheck] Error 1
make[1]: Leaving directory 
`/home/jcalcote/dev/prj/ti-test/zardoz-1.0/_build'

make: *** [distcheck] Error 2
$

I have to add this line to the Makefile.am file to get the distcheck 
target to work cleanly:


CLEANFILES = zardoz.dvi

It appears that make clean is leaving the dvi file in place. In fact, 
when I manually execute make clean, after make dvi, I get the following 
output:


test -z "zardoz" || rm -f zardoz
rm -rf zardoz.aux zardoz.cp zardoz.cps zardoz.fn zardoz.fns zardoz.ky \
  zardoz.kys zardoz.log zardoz.pg zardoz.pgs zardoz.tmp \
  zardoz.toc zardoz.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

cross-compiling on 64 to 32-bit Linux

[John Calcote]

Hi everyone,

I was wondering what the procedure was for cross-compiling 32-bit apps 
on a 64-bin Linux system? Do you need special libraries. What 
command-line options are used? That sort of thing. I'm happy to read up 
on it, if there are references that you can point me to.


Thanks in advance,
John

Re: My project can't use `silent-rules'

[John Calcote]

Hi Bob,

On 5/17/2009 11:05 PM, Bob Friesenhahn wrote:

On Mon, 18 May 2009, Ralf Wildenhues wrote:


You can use
 AM_SILENT_RULES


Worked! Thanks!

Unfortunately, it does not silence the warnings from my code.


Forgive me, but do you really want it to do this?

Of course, if you want to permanently silence warnings from your code, 
you should probably just use appropriate pragmas or command-line options 
to disable those warnings.


One of the primary reasons (IMHO) for Automake silent rules is so that I 
CAN see the warnings in my code (without resorting to redirecting make's 
stdout 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

Re: Setting shared lib version not functioning

[John Calcote]

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
with a version number of 1:1:0. Now, why would Libtool do this? Granted,
he didn't really want 2:0:1, but 2:0:1 isn't a bogus triplet, either. So
why did Libtool convert it to 1:1:0?
 


For the linux way of library versioning the library suffix is computed
as (current-age).age.revision, thus 2:0:1 maps to 1.1.0.  A libtool
version of 1:1:0 whould map to 1.0.1.
   
Thanks Andreas. This is excellent information, but I'd like to 
understand why this is so. Can you point me to a reference that 
describes this transformation, and perhaps it's rationale?


Thanks in advance,
John

Re: Setting shared lib version not functioning

[John Calcote]

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 of some sort, rather than simply
generate code with a different version number.
 


I agree with Jan that it is not safely possible for libtool to detect
such errors.  It detects bogus triplets such as 3:0:5, but even if it
were to look at the prior uninstalled or installed version of the
library it is about to (re)create, there is nothing that reveals whether
the triplet in the prior version was wrong, rather than the one to be
used.  So, while we could output a warning such as
   libtool: warning: library version `...' not compatible with previous `...'

I'm not sure how much good it would do.
   
When I said "ridiculous cases" I really meant "bogus triplets". I didn't 
think there was much you could do about valid triplets that are simply 
incorrect. I should think that Libtool might fail a build if a bogus 
triplet is passed, however.


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 with a version number of 1:1:0. Now, why would Libtool do this? 
Granted, he didn't really want 2:0:1, but 2:0:1 isn't a bogus triplet, 
either. So why did Libtool convert it to 1:1:0?


John

Re: Effects of some references to other libraries in a shared library

[John Calcote]

Gerald,

On 5/3/2009 3:32 PM, Gerald I. Evenden wrote:

In a shared library there are about 8 routines out over 100 that refer to
libgsl and libpthread.  A frequent situation may arise where an application
program has no need for using the 8 procedures infected with other library
needs.

At the current time, when I try to link such a program I get a failure unless
I add all the references to the additional libraries---even though they are
not employed by the program in any manner.

Is there any reasonable way around this or do I have to either separate the 8
routines into another library or add the references to libgsl (+*blas) and
pthread to Makefiles of programs that have no involvement with these library
procedures?
   
There are two options: one you mentioned already - separate the 8 
routines into another library. The other option involves manually 
loading importing the routines 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

Re: Setting shared lib version not functioning

[John Calcote]

Gerald,

On 5/3/2009 12:40 PM, Gerald I. Evenden wrote:

I want to thank you all for the assistance, however I still find the libtool
manual not very illuminating.  In particular, I used section 7.3 in make my
release number and, in particular, item 5 related to adding an interface
since last release as causing an addition to "age."

The big problem here is the three number do not seem independent, which
compounds the problem.  Perhaps item 3 was what should have changes but item
5 clause was also true.
   
The numbers aren't independent at all. Don't try to make the library 
interface version components into a software revision number. The scheme 
is the way it is because the OS library loader uses the values in these 
fields to determine if a particular library will support a particular 
interface request. When a program attempts to load a library versioned 
1.0.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

Re: Setting shared lib version not functioning

[John Calcote]

Hi Gerald,

On 5/3/2009 9:51 AM, Jan Engelhardt wrote:

On Sunday 2009-05-03 17:41, Gerald I. Evenden wrote:

   

libproject_la_LDFLAGS = -version-info 2:0:1

which worked fine when with previous loading of a library with 2:0:0
versioning code.

But now, when I go through the autoreconf, configure, compile and install I
get:

libproject.so.1.1.0
 


Which is absolutely correct. Either you wanted 2:1:0, or 3:0:1 (just
a guess though, I can't read minds).
Have a look at `info libtool`, section Versioning::.
   

Hmmm. Jan is correct in his analysis of your versioning strategy.

current : revision : age

You really have no reason to increment only the age value of a library 
version. What you're implying by this new version of 2.0.1 is that this 
particular instance of your library is identical in every way to the 
previous version of 2.0.0, except that this one is now backward 
compatible with a prior version (1.x.y).


If you made changes to the library, but did not in any way modify the 
interface, then you probably want to use version 2.1.0. If you modified 
the interface in a manner that's 100% backward compatible with the 
previous version, then you probably want 3.0.1. If you modified the 
interface in a manner that is NOT backward compatible (i.e., you removed 
an API function), then you probably want 3.0.0.


It appears that Libtool is smart enough to detect ridiculous cases, but 
it should probably throw an error of some sort, rather than simply 
generate code with a different version number.


Adding the libtool list.

Regards,
John

Re: Setting output dir for support files

[John Calcote]

Hi Robert,

On 4/30/2009 11:07 PM, Robert J. Hansen wrote:

I've used Autotools in a few small projects before, but nothing which
required auxiliary files to support the binaries.  Typically, I've seen
these auxiliary files stored in /usr/share/package-version/, and would
like to do the same thing for my own package via Autotools.

I'm able to get /usr/share (or, more accurately I guess, $PREFIX/share)
just by using ${datadir} in my Makefile.am.  However, I can't shake the
feeling that (a) this is the wrong way to do it, and (b) if I hardwire
paths that way I'll be stuck maintaining my error for quite some time to
come.

So, my questions:

1.  What's the correct way to do this?  I'm assuming there's some
 configure.ac and Makefile.am changes which need to be made, but
 I'm not sure which.
   
Use dist_pkgdata_DATA instead of dist_data_DATA. However, by default 
pkgdatadir is datadir/$(PACKAGE). If you want the version on the 
directory also, you'll have to redefine pkgdatadir to include 
$(VERSION), as shown below...



2.  How can I make dist_data_DATA install to this directory?  (If I
 should be using a different target, please say so!)
   


Makefile.am:

pkgdatadir = $(PACKAGE)-$(VERSION)
dist_pkgdata_DATA = ...


3.  How can I, programmatically within my C code, find the dirs in
 which my auxiliary files have been placed?
   

Makefile.am:
...
myprogram_CPPFLAGS = -DPKGDATADIR="\"$(pkgdatadir)\""

-
source_file.c:
...
#ifndef PKGDATADIR
# error PKGDATADIR not defined
#endif

const char mydatatadir[] = PKGDATADIR;
...


I apologize for the elementary question, but Google has been pretty much
no help, and studying how other projects have done it has been less than
informative.  :(
   
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

Re: noinst_TEXINFOS

[John Calcote]

On 4/29/2009 5:27 PM, Ben Pfaff wrote:

Stefan Bienert  writes:

   

Could it be that a primary

noinst_TEXINFOS

does not work with automake 1.10.2?
 


This seems likely.  I reported the same problem some time ago:
  http://permalink.gmane.org/gmane.comp.sysutils.automake.bugs/4046
My 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

Re: Create a custom target

[John Calcote]

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:

Hi John

Thanks a lot it worked and
it made  my day :-)

I would really appreciate if you could pass me some useful links regarding
automake.

I wonder where do we get those big target list automatically appended to
all.I would like to know more about automake.




Sure, just add it to the all-local target as a dependency, like this:

all-local: extra

--john





   

Re: Create a custom target

[John Calcote]

On 4/22/2009 8:54 PM, automake wrote:

Hi
  I have a similar problem with giving a customized target. I have included
target into Makefile.am

as

extra:
   ...nm
   ...link

But the default target for makefiles from configure.ac is all.  Is there a
way to add this target to all sub-targets?
   

Sure, just add it to the all-local target as a dependency, like this:

all-local: extra

--john

Re: Example on JNI compilation

[John Calcote]

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 already builtin. Does anybody know an example
of how a jni lib is built using automake?
   

There are basically two steps to building JNI libraries:
 


Note that on Mac OS X 10.4 and earlier, java will not load modules that
do not have a ".jnilib" extension, so you should add somewhere in
configure.ac, something like:

case $host_os in
*-darwin*)
JNI_EXTRA_LDFLAGS="-shrext .jnilib" ;;
esac
AC_SUBST(JNI_EXTRA_LDFLAGS)

then in your Makefile.am you can have:
mylib_la_LDFLAGS = -module -avoid-version $(JNI_EXTRA_LDFLAGS)

Peter
   
Thanks Peter, I didn't know this. I guess it won't be long before this 
isn't really an issue for newer macs, as 10.6 will probably be released 
in June, thereby bringing 10.4 to end-of-life state. However, there will 
still be plenty of older mac users out there.


I might as well ask this question here: We build a regular C/C++ shared 
library, and link our JNI stubs right into it, exporting the JNI 
interfaces right along side the native library interfaces. It seems to 
work well on the platforms we've tried it out on, and it saves a 
library. In fact, we do the same thing with our C# (mono) interfaces, so 
this library has a hefty exported API.


Besides the issue you pointed out above where JNI libs require a 
specific extension, do you know of any other issues with doing this sort 
of thing?


Thanks in advance,
John

Re: Example on JNI compilation

[John Calcote]

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 already builtin. Does anybody know an example 
of how a jni lib is built using automake?

There are basically two steps to building JNI libraries:

1. Use the javah utility to generate JNI prototypes in C-language header 
files from your Java source code.
2. Compile the C-language JNI sources (including the headers generated 
in step 1) into a library.


Step 1 above is pure Java-speak, and Automake has little built-in 
functionality for it. Step 2, however is pure gcc, and Automake has no 
trouble with it. For an example of how to integrate javah operations 
into Makefile.am so you can do it all from Automake, see Chapter 6 of 
this online book at freesoftwaremagazine.com:


  http://www.freesoftwaremagazine.com/books/agaal/autotools_example

Search for the text, "Building the JNI C++ sources".

Regards,
John

Re: DESTDIR vs `make install exec_prefix='

[John Calcote]

On 4/18/2009 2:32 PM, Jan Engelhardt wrote:

On Saturday 2009-04-18 22:06, Russ Allbery wrote:
   

Russ Allbery  writes:
 

Ralf Wildenhues  writes:
   

[1] I'm asking because Automake 1.11 will reliably not install files if
their respective installation directory is empty.  This is not yet
functional in Automake 1.10.2.  The test for emptiness in 1.11 will not
consider $(DESTDIR) of course, only $(bindir) etc.
 

I must have misunderstood this, since it sounds like it would potentially
break any system where each binary package is installed into a separate
tree.  For example, stow packages are routinely installed with:

 ./configure --prefix=/usr/local
 make
 make install prefix=/usr/local/stow/package-version

DESTDIR cannot easily be used here because the stow layout should have
simple bin, etc, lib, etc. directories directly under that directory, not
with an extra /usr/local in the way.
   

Oh, you mean if the value of the *variable* is empty (following the
thread), not the directory itself.  D'oh, sorry, that should have been
obvious to me from context.  Never mind.  :)
 


No, I also thought of empty directories. Quote from above: "respective
installation directory is empty.". But the puzzling thing was that
when using DESTDIR=$foo, $foo would normally be empty anyways
(in automated build systems like lbuild/koji/etc.)
   
I'm sure he meant "...respective installation directory *variable* is 
empty.". 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

Re: Doxygen and Autotools

[John Calcote]

Hi Lorenzo,

Please see my on-line Autotools book at freesoftwaremagazine.com. It 
covers extensively the use of doxygen as an add-on to Autoconf and 
Automake.


http://www.freesoftwaremagazine.com/books/autotools_a_guide_to_autoconf_automake_libtool

Chapters 6 and 7 deal more specifically with 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 developing with autotools.


I found this macro 
http://autoconf-archive.cryp.to/ax_prog_doxygen.html and this example 
http://www.bioinf.uni-freiburg.de/~mmann/HowTo/automake.html


however, from what I understand, the macro and the example do not deal 
with installation of doxygen generated documentation, do they?


any suggestion for using doxygen with autotools?

thanks in advance
Lorenzo

Re: aclocal problems

[John Calcote]

By the way, you may be interested in seeing how I was able to use
m4_define and still get aclocal to use my file for gnulib's AC_DEFUN_ONCE
replacement (coupled with an AC_REQUIRE([gl_00GNULIB]) in gnulib-common.m4):
http://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/00gnulib.m4
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

Re: aclocal problems

[John Calcote]

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 macros required by other macros inside
arguments do not need to be expanded before this macro, then use
m4_define."
 

...

Is this a bug in aclocal?
 


I don't think so.  Do you think the quote is an encouragement not to use
AC_REQUIRE?  For public macros, I'd even venture to say that they should
be written so they can be AC_REQUIREd (if they don't take arguments), or
at least, that other macros which are expanded inside their contents or
their arguments, may themselves AC_REQUIRE yet other macros which are
then expanded outside of all this mess.
   
Hmmm. No, I don't think it's an encouragement not to use AC_REQUIRE. It 
simply states that if you don't use the prerequisite framework, there's 
no reason to use AC_DEFUN. I supposed that from a certain point of view 
(a rather sarcastic one), it could be saying something like, "if ever 
you could conceive of a situation in which you wouldn't need to use 
AC_REQUIRE, then go ahead and use m4_define."


I agree completely with your assessment, but I think the manual should 
make it clear that the only proper way to write a macro is with 
AC_DEFUN, don't you? I mean, if the only way I can write a macro outside 
of adding it directly to configure.ac (which is pointless in all but the 
strangest cases) is to use AC_DEFUN, then *when* would I ever be able to 
successfully use m4_define? I suppose it might work in acsite.m4, as 
that's not included by aclocal.m4.


My only point is that the manual is a bit unclear on this point - almost 
misleading, in fact.


I'd call it a documentation bug at this point. (Eric - comments?)

Regards,
John

aclocal problems

[John Calcote]

Automake maintainers,

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 macros required by other macros inside 
arguments do not need to be expanded before this macro, then use m4_define."


So the Autoconf manual is encouraging users to use m4_define, however, 
when I define a macro using m4_define in a .m4 file in the m4 directory 
of my project, aclocal ignores it by not m4_including it in the 
generated aclocal.m4 file. It appears to require the use of 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

Re: Finding library procedures in /usr/local/lib/

[John Calcote]

On 4/3/2009 12:29 PM, Ralf Wildenhues wrote:

Hello Gerald,

* Gerald I. Evenden wrote on Fri, Apr 03, 2009 at 08:11:22PM CEST:
   

One added note, that bothers me a little.

If the system checks for an entry being present in a particular iibrary by
compiling/linking a test program using the function *and* linking to the
specified library,>  what if the library under test heavily references
another library such as -lm??  IF -lm is not in the test run would the test
not fail???  Thus the entry under test fails also.
 


I haven't read the thread in full, but this is probably the issue
bothering you:

AC_CHECK_LIB and AC_SEARCH_LIBS both have an optional 5th argument where
one can supply additional needed libraries.  So of libfoo needs libm,
then a check for libfoo could look like

   AC_SEARCH_LIBS([function_from_libfoo], [foo], [], [], [-lm])
   
I sure don't know what's happening to my email messages lately. This is 
the third time this month that some response of mine has apparently been 
completely lost by Google mail. I sent this response to this thread last 
night (via Mozilla Thunderbird client), which goes hand-in-hand with 
Ralf's response above, but provides more details:


- - - - - -

I presume that the reason you link with both libproject and the math 
library is because libproject requires libm. This could explain why your 
configure.ac tests are failing to "find" libproject. Try adding this 
test to configure.ac:


AC_SEARCH_LIBS([any_visible_function_in_libproject],[project],[AC_DEFINE([HAVE_LIBPROJECT])],,[-lm]) 



Tests in configure.ac "look" for libraries by actually building programs 
that attempt to link the specified symbol from the specified list of 
libraries. If the program links, then the test succeeds. The default 
action in successful cases for AC_SEARCH_LIBS is to add "-lprojects" to 
the LIBS variable, which is automatically added to your compiler command 
line (at least by Automake-generated makefiles). If the library that 
AC_SEARCH_LIBS attempts to link to requires other non-default libraries 
(like libm, for instance), then you have to add this list of linker 
commands to the "other-libraries" argument, or the test will fail, even 
if the function is found in the desired library.


The documentation for AC_SEARCH_LIBS indicates that, on successfully 
testing for the desired library, this macro prepends -lproject to LIBS, 
and then executes the shell code in the "action-if-found" parameter, 
thus, you don't need to add -lproject to LIBS, because this is done by 
the macro before any additional shell code you specify is executed.


You can also use the following macro, which generates shell code that is 
a little less complex. But it's a bit harder to use correctly, as you 
have to write the entire "action-if-found" functionality yourself. The 
carriage returns are fairly important here:


AC_CHECK_LIB([project],[any_visible_function_in_libproject],
[LIBS=-lproject $LIBS
AC_DEFINE([HAVE_LIBPROJECT])],,[-lm])

AC_CHECK_LIB has no success functionality that executes 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.


You might also check the config.log file for failed tests that you 
believe 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

Re: problem to create a "noinst_LTLIBRARIES" shared libraray

[John Calcote]

Andreas,

On 4/3/2009 3:26 AM, Andreas Otto wrote:

  I currently writing a java JNI extension used only for local "check" and
  this library should *not* be installed.
   

...

Question: what can I do to get a shared LTLIBRARIES using the "noinst"
prefix ?
   


Use check_LTLIBRARIES instead of noinst_LTLIBRARIES.
Check libraries and programs are not installed either.

Regards,
John

Re: Finding library procedures in /usr/local/lib/

[John Calcote]

On 4/3/2009 8:49 AM, Gerald I. Evenden wrote:

On Thursday 02 April 2009 5:56:52 pm Peter Johansson wrote:
   

Hello Gerald,

Gerald I. Evenden wrote:
 

After trying so many options related to libraries I am exhausted.

I have a simple program that needs to link with a shared library
installed in /usr/local/lib.

When using my own simple Makefile and simply adding "-lproject -lm"
everything works fine (libproject is the shared library).
   

LDADD = "-lm -lproject"

in your `Makefile.am' should do it.

Cheers,
Peter
 


Of the suggestions offered, this one worked in the following literal entry
into src/Makefile.am:

geodesic_LDADD = -lproject -lm
   
No offense intended to Peter, but this solution works because it simply 
assumes the library exists on the end-user's system. On systems where it 
doesn't exist in the default library 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

Re: Finding library procedures in /usr/local/lib/

[John Calcote]

On 4/2/2009 3:45 PM, Gerald I. Evenden wrote:

After trying so many options related to libraries I am exhausted.

I have a simple program that needs to link with a shared library installed
in /usr/local/lib.

When using my own simple Makefile and simply adding "-lproject -lm" everything
works fine (libproject is the shared library).

But regardless of how many tests, etc., I do in the .ac and .am files I cannot
get the final Makefile to link with "project."

There must be a simple solution to this rediculously simple operation but the
*^%(*% manuals are forever enamored with the complex examples and give short
time to the dumb oxes as myself.

Also, whenever I put tests for the existance of the library entries in
configure.ac output of ./configure always shows that they are not detected.
   
You might also check the config.log file for failed tests that you 
believe 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

Re: Finding library procedures in /usr/local/lib/

[John Calcote]

Gerald,

On 4/2/2009 3:45 PM, Gerald I. Evenden wrote:

After trying so many options related to libraries I am exhausted.

I have a simple program that needs to link with a shared library installed
in /usr/local/lib.

When using my own simple Makefile and simply adding "-lproject -lm" everything
works fine (libproject is the shared library).

But regardless of how many tests, etc., I do in the .ac and .am files I cannot
get the final Makefile to link with "project."
   
I presume that the reason you link with both libproject and the math 
library is because libproject requires libm. This could explain why your 
configure.ac tests are failing to "find" libproject. Try adding this 
test to configure.ac:


AC_SEARCH_LIBS([any_visible_function_in_libproject],[project],[AC_DEFINE([HAVE_LIBPROJECT])],,[-lm])

Tests in configure.ac "look" for libraries by actually building programs 
that attempt to link the specified symbol from the specified list of 
libraries. If the program links, then the test succeeds. The default 
action in successful cases for AC_SEARCH_LIBS is to add "-lprojects" to 
the LIBS variable, which is automatically added to your compiler command 
line (at least by Automake-generated makefiles). If the library that 
AC_SEARCH_LIBS attempts to link to requires other non-default libraries 
(like libm, for instance), then you have to add this list of linker 
commands to the "other-libraries" argument, or the test will fail, even 
if the function is found in the desired library.


The documentation for AC_SEARCH_LIBS indicates that, on successfully 
testing for the desired library, this macro prepends -lproject to LIBS, 
and then executes the shell code in the "action-if-found" parameter, 
thus, you don't need to add -lproject to LIBS, because this is done by 
the macro before any additional shell code you specify is executed.


You can also use the following macro, which generates shell code that is 
a little less complex. But it's a bit harder to use correctly, as you 
have to write the entire "action-if-found" functionality yourself. The 
carriage returns are fairly important here:


AC_CHECK_LIB([project],[any_visible_function_in_libproject],
[LIBS=-lproject $LIBS
AC_DEFINE([HAVE_LIBPROJECT])],,[-lm])

AC_CHECK_LIB has no success functionality that executes 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

Re: silent build rules

[John Calcote]

While we're on the issue of Automake silent rules, I've got a comment 
about Libtool hiding half of it's compiles.(Thus, I've added the libtool 
list as well.)


I was recently building a project that failed without an error message, 
while running under "non-silent" mode, or the original GNU build noise 
level. This puzzled me to no end until I realized that the error was 
occurring in one of the two (pic/non-pic) compiles that libtool shuffles 
off to /dev/null. The error was regarding global labels found in in-line 
assembly, that -fPIC builds didn'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, Bob Friesenhahn wrote:

On Wed, 1 Apr 2009, Ralf Wildenhues wrote:


* Eric Blake wrote on Wed, Apr 01, 2009 at 08:52:36PM CEST:

According to Bob Friesenhahn on 4/1/2009 12:40 PM:


It seems that I will need to permanently define and export the 
arbitrary

variable 'V' in my shell environment in order to avoid confusion later
since I won't know how a build will behave until I type 'make'.  That
leaves 25 more single-letter variables for my own use.


The rationale for keeping V was that users accustomed to the Linux build
system would not have to relearn.  Maybe that is not such a good
rationale: those who build the kernel regularly are hardly the least
experienced users.


More significantly, GNU users are not restricted to the Linux kernel 
or having any Linux experience at all.  What feels normal for a Linux 
user may be bizarre for a non-Linux user.


My opinion is that if this mode is optional that it should default to 
"off" and that an action taken by the user (dot file, environment 
variable, configure option) to declare a personal preference can be 
used to trigger the Linux mode.  Perhaps additional build modes would 
be contributed in the future.



Hopefully it won't alter the behavior of other scripts or builds.


As I wrote off-list already, unless you use the 'silent-rules' option
for your packages, your code should be built as always.


This new m4 release is the first package I have seen with this 
automake "Linux mode".  I checked it for a special automake option and 
did not find it so I assume that it was provided when m4 was manually 
bootstrapped.



the default verbosity level that they are comfortable with.  Something
like './configure --disable-silent-rules' to request the V=1 behavior?


It is wrong to change the default from the convention used by GNU 
packages for at least 20 years.  GNU packages should all build the 
same by default.  This year's package should build similar (by 
default) to last-year's package.


Users of complex packages like my own would suffer severely if they 
build in Linux mode by default.  Users of simple stand-alone packages 
like 'm4' are unlikely to suffer.



This is an open problem, and mentioned here:

Suggestions welcome.


A configure flag to set the user-preferred default is reasonable, as 
long as the default is the traditional "GNU" mode.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, 
http://www.simplesystems.org/users/bfriesen/

GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

Re: Convenience programs

[John Calcote]

Russell,

On 4/1/2009 4:47 AM, Russell Shaw wrote:

Hi,
In //keysyms, i have a Makefile.am and it generates a 
"genkeysyms" program

in C.

//src contains a Makefile.am and it generates source files in this
directory using ../keysyms/genkeysyms, then uses these sources in the 
rest

of the compile.

//src/Makefile.am has:

keysyms.tab.include: ../keysyms/genkeysyms
../keysyms/genkeysyms


make distcheck reports:

  ../keysyms/genkeysyms
  make[3]: ../keysyms/genkeysyms: Command not found


How do i get //keysyms/genkeysyms built first? Do i add(?):

../keysyms/genkeysyms:
make -C ../keysyms


/Makefile.am should contain:

SUBDIRS = ... keysyms ... src ...

Just makesure keysyms is given before src in that list.

Regards,
John

Re: Sample plugin project

[John Calcote]

Santiago Capel Torres wrote:
> Hi I'd like to know of any sample or small c++ project for GNU/Linux
> which uses any kind of loadable plugins with the ld library. It should
> be complete in the sense of having all the autotools files and the c/c++
> code of both the main application and the plugins.
>
>
> Thanks a lot!
> -- santilin
>
>
>
>
Santiago,

This may be more than you need, but "Chapter 5: Building Shared
Libraries with Libtool" of my book, "Autotools: A Practitioner's Guide
to Autoconf, Automake, and Libtool" contains a reasonably complete
description of how to implement a build system for a loadable "plugin"
library service.

The complete on-line version of the book is available at Free Software
Magazine's book section:

http://www.freesoftwaremagazine.com/books/autotools_a_guide_to_autoconf_automake_libtool

Regards,
John

Re: Doxygen + Autotools integration

[John Calcote]

Stefano D'Angelo wrote:
> 2008/10/3 Stefano D'Angelo <[EMAIL PROTECTED]>:
>   
>> 2008/10/2 John Calcote <[EMAIL PROTECTED]>:
>> 
>>> You may wish to check out my book on Autotools, hosted by Free Software
>>> Magazine. In there, I make several references to doxygen, and use code
>>> snippets to implement doxygen targets within the sample projects and
>>> examples provided in the book.
>>>
>>> http://www.freesoftwaremagazine.com/books/autotools_a_guide_to_autoconf_automake_libtool
>>>   
>> Well... at first sight the whole thing seems a bit "simplicistic" to
>> me, maybe also because I'm generating html, ps, pdf, dvi and man
>> output with Doxygen. I'll give it a better look tomorrow maybe.
>> 
>
> Ok, read it. I have to congratulate with you for the manual, which
> looks way better than the "autobook" (and less outdated of course),
> but as said, the proposed solution wouldn't satisfy my needs.
>
> Other than that, I think you could have used AC_CHECK_PROG instead of
> AC_CHECK_PROGS to look for the doxygen binary, since it already does
> the -z test on the variable used to store its path, thus you wouldn't
> need the AC_PROG_TRY_DOXYGEN macro.
Stefano,

I apologize for my lack of communication here. I didn't mean to ever
imply that my solution was the best one out there. I was simply giving
you some more resources to look at for building your generic doxygen
solution. I only hope it was helpful.

Cheers,
John

Re: Doxygen + Autotools integration

[John Calcote]

You may wish to check out my book on Autotools, hosted by Free Software
Magazine. In there, I make several references to doxygen, and use code
snippets to implement doxygen targets within the sample projects and
examples provided in the book.

http://www.freesoftwaremagazine.com/books/autotools_a_guide_to_autoconf_automake_libtool

I throw these references out into the list sometimes because people come
and go, and every few months, I noticed an increasing number of
questions regarding topics that are mentioned in detail in the book.

Regards,
John

Peter Johansson wrote:
> Hi Stefano,
>
> Stefano D'Angelo wrote:
>> 2008/10/2 Peter Johansson <[EMAIL PROTECTED]>:
>>  
>>> Hi Stefano,
>>> 
>>
>> Hi Peter,
>>
>>  
>>> Have you checked the macro written by Oren Ben-Kiki that is
>>> available from
>>> the Autoconf Macro Archive:
>>> 
>>
>> Yes (I also named that in my prevoius e-mail -
>> http://www.ben-kiki.org/oren/doxample)
> Sorry, I missed that.
>
>> , and I'm not the only one to
>> think that it sucks on many fronts.
>>   
> Well, I have to admit that when I looked at it a couple of years ago,
> I chose to not use it.
>
> Looks like what I instead created is similar to your example. Will
> have a closer look at your Makefile.am to see if I can pick up any
> improvements. Thanks.
>
>
> Cheers,
> Peter
>
>
>
> ___
> Autoconf mailing list
> [EMAIL PROTECTED]
> http://lists.gnu.org/mailman/listinfo/autoconf
>

Re: Problems with conditional sources

[John Calcote]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andreas Schwab wrote:
> John Calcote <[EMAIL PROTECTED]> writes:
> 
>> Andreas Schwab wrote:
>>> John Calcote <[EMAIL PROTECTED]> writes:
>>>
>>>> Make is a two-pass utility. The first pass completely assimilates all
>>>> macro data specified in the Makefile. THEN, the second pass generates
>>>> the rule dependency tree.
>>> This is not true.  Variable refences in target and dependency lists are
>>> expanded when they are read.  Any later redefinition will not change
>>> them.
>>>
>>> Andreas.
>>>
>> This is only true if you use ':=' assignment.
> 
> You are mistaken.  RTFM.
> 
> Andreas.
> 
Andreas,

My mistake. I apologize. I actually have RTFM, but it's been a while. :)

John
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAki0IxsACgkQdcgqmRY/OH9MAwCcCxLbm3FiIcwF+nr1T8fiTesW
3VIAn3Lj9yKb/Krord08VTlhZZmuqvLr
=F0Ls
-END PGP SIGNATURE-

Re: Problems with conditional sources

[John Calcote]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andreas Schwab wrote:
> John Calcote <[EMAIL PROTECTED]> writes:
> 
>> Make is a two-pass utility. The first pass completely assimilates all
>> macro data specified in the Makefile. THEN, the second pass generates
>> the rule dependency tree.
> 
> This is not true.  Variable refences in target and dependency lists are
> expanded when they are read.  Any later redefinition will not change
> them.
> 
> Andreas.
> 

This is only true if you use ':=' assignment. In this case (only),
variable *assignments* are expanded immediately. But regular rule or
command references are only expanded when the rule or command is
evaluated (as opposed to read).

John
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAkizKkoACgkQdcgqmRY/OH+JugCcDG2tUysq3zD5wNFdNMbUC3BS
OAEAoI7g643zoZqOVUafU9grcAOBOmWi
=LoRe
-END PGP SIGNATURE-

Re: Problems with conditional sources

[John Calcote]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andreas Schwab wrote:
> David Sveningsson <[EMAIL PROTECTED]> writes:
> 
>> Hi, I am having some problems with conditional sources. This is what I
>> have in Makefile.am:
>>
>> lib_LTLIBRARIES = libfoo.la
>> libfoo_la_SOURCES = foo.cpp
>> if WANT_BAR
>>  libfoo_la_SOURCES += a.cpp
>> else
>>  libfoo_la_SOURCES += b.cpp
>> endif
>>
>> AM_CPPFLAGS = -I${top_srcdir}/include
>> libfoo_la_LDFLAGS = -version-info 0:0:0
>>
>> I have been reading both autoconf and automake manuals and as far as I can
>> see the above should work. However the files (a.cpp or b.cpp) is always
>> added at the bottom of the generated Makefile and are therefore not used
>> in the compilation. No matter what I try I cannot get even the above code
>> to generate a correct makefile but obviously I am doing something wrong.
> 
> Remove the indentation.

Duh. Of course. But the actual answer is to not indent with TAB characters.

John
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAkizKagACgkQdcgqmRY/OH8feACglzA/fX3HrTW6VZJgTeuHbg/F
LsUAnj91T+13NdbPMiIanGWHkrQ2kvLp
=qTXY
-END PGP SIGNATURE-

Re: Problems with conditional sources

[John Calcote]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> While that would make sense but my problem originates from the fact that
> the conditional files isn't compiled.
> 
> After some hacking into the generated Makefile I noticed that the files
> wouldn't be compiled even if I inserted them into libfoo_la_SOURCES
> manually. However, I found that I had to inserting them into
> am_libfoo_la_OBJECTS with the lo extension to make it work. Shouldn't
> automake manage this?
> 
> I am just learning autotools so it might be a very simple mistake.

Yes, I'm so sorry. I got so interested in addressing the issue of macro
location in the Makefile, I forgot to answer your original question.

Frankly, from what you've presented, I can't see any reason why you're
experiencing that behavior. You're absolutely right - automake should
(and usually does) handle conditionals without a hitch.

How does WANT_BAR get assigned? Do you have an AM_CONDITIONAL statement
for WANT_BAR in your configure.ac file?

Perhaps you could send along relevant portions of the generated
Makefile. I know they're big, but just clip out the stuff you think is
important.

John
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAkizHyYACgkQdcgqmRY/OH++dQCfRlaIjJjHcNN85cjBkkC+frc+
1n8AoIzxdDTw5ghPvqVQ6G/RIBHP+wWD
=7iV/
-END PGP SIGNATURE-

Re: Problems with conditional sources

[John Calcote]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

David Sveningsson wrote:
> Hi, I am having some problems with conditional sources. This is what I
> have in Makefile.am:
> 
> lib_LTLIBRARIES = libfoo.la
> libfoo_la_SOURCES = foo.cpp
> if WANT_BAR
> libfoo_la_SOURCES += a.cpp
> else
> libfoo_la_SOURCES += b.cpp
> endif
> 
> AM_CPPFLAGS = -I${top_srcdir}/include
> libfoo_la_LDFLAGS = -version-info 0:0:0
> 
> I have been reading both autoconf and automake manuals and as far as I
> can see the above should work. However the files (a.cpp or b.cpp) is
> always added at the bottom of the generated Makefile and are therefore
> not used in the compilation. No matter what I try I cannot get even the
> above code to generate a correct makefile but obviously I am doing
> something wrong.

David,

Make is a two-pass utility. The first pass completely assimilates all
macro data specified in the Makefile. THEN, the second pass generates
the rule dependency tree. AFTER the second pass, the tree is evaluated
to see what needs to be rebuilt.

Thus, it doesn't matter where macros are assigned, as value assignments
to macros are managed in the first stage, before any macros are ever
expanded when the dependency tree is evaluated.

Yes, as you've noticed Makefile.am conditional (and non-conditional)
macro assignments are added to the bottom of the generated Makefile.in
(and consequently to the bottom of the Makefile itself), but the point
is that it doesn't matter where they're added. The value of an expanded
macro always takes into account the final assignment in the Makefile.

Regards,
John
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAkizDcwACgkQdcgqmRY/OH8NAgCfXOzWSB8JYAMIqJhC0xCcdj9E
j6wAoJxLNUc1t4YPp0pnn0G6PSCOntpY
=uEnf
-END PGP SIGNATURE-