Re: RE : call for help/crazy idea: nmake support

[Braden McDaniel]

On Fri, 2010-08-13 at 19:18 +0200, Ralf Wildenhues wrote:

[snip]

> And of course I would be delighted if some of you provided fixes
> for pkg-config and whetever else is needed to make building for
> this setup work better.

The problem with pkg-config is that it relies a lot on POSIXy
development environment conventions.  And outside of systems that
provide such a development environment on Windows, there's no
conventional place to put pkg-config's *.pc files.  And if there were,
you'd need to get various SDK installers to start using it.  Oh, and my
own experience is that I wind up using library dependencies that don't
even have "installers" per se; so in these cases a *.pc file would need
to be manually constructed.

I'm quite happy just adding -I and -L flags to CPPFLAGS and LDFLAGS as
necessary.

-- 
Braden McDaniel 

Re: RE : call for help/crazy idea: nmake support

[Braden McDaniel]

On Wed, 2010-08-11 at 08:34 +0200, PICCA Frédéric-Emmanuel wrote: 
> Hello
> 
> > I'm certainly quite eager to see this in Automake and Libtool.  I
> > suspect this will hit the sweet spot for a lot of autotools users.
> 
> the problem I see is that a lot's of peoples relies on pkg-config
> during the configuration phase.
> 
> How can we deal with this on windows platform ?

I think the answer is that you can either augment or replace use of
pkg-config.

I suspect anyone expecting these changes to libtool to make autotools
packages Just Work on Windows will be disappointed.  And I would be
shocked if pkg-config is the only reason for that.

-- 
Braden McDaniel 

Re: call for help/crazy idea: nmake support

[Braden McDaniel]

On Tue, 2010-08-10 at 16:38 -0700, Natalie Tasman wrote: 
> Hi Ralf,
> 
> I think this is a great idea and would be interested in hearing your
> plans for moving forward.  I've invested a lot of time in an autotools
> build system that works on *nix and mingw (and cross-compiling to
> mingw from linux!) and I do think this would be interesting to see
> this work on mingw shell with MSVC's build system, as you propose.
> 
> Although, to be honest, I have recently been taking another look at
> other build systems such as cmake, which does generate full
> MSVC-native project files, which is very attractive.  I'm sure this is
> heresay, but I'll at least voice my interest in a dream solution:
> autotools with Visual Studio project file generation.

Part of the problem with Visual Studio project file generation is the
frequency with which the file format changes--sometimes a little,
sometimes a lot.  But every couple of years or so, something's likely to
change.

msbuild (of which I understand modern project file formats to be a
subset) might be a better target.  The long term stability of the file
format doesn't have much of a track record yet; but one can choose to be
optimistic.  It does deliver a command line build without a Bourne
shell, which I'm guessing is the major attraction of nmake.  But unlike
nmake, it has quite a few modern features.

> A related, possibly basic question: if mingw's gcc builds
> msvc-compatible DLLs, etc, what do people see as the benefit to using
> a mingw/sh-driven MSVC build?

Good enough for C; but if you wants to build a DLL with C++ interface
features, you generally still need to use the same compiler as other
code you're playing with.

-- 
Braden McDaniel 

Re: call for help/crazy idea: nmake support

[Braden McDaniel]

On Sat, 2010-07-31 at 19:26 +0200, Ralf Wildenhues wrote: 
> Here's a crazy idea: how about if automake optionally output an input
> file suitable for nmake (after configure substitution)?
> Is that even feasible?  (I'd guess so)
> Maybe if we have contents conditional on 'make' or 'nmake' output?
> Would that even help anybody?  (no idea)
> Is there anybody willing to work on this?
> Should I prepare a Summer of Code/other code sprint project proposal[1]?

nmake really does live in a different universe.  Just for example,
CPPFLAGS are for the C++ compiler in nmake, not the preprocessor.  And
is nmake really used for anything nontrivial these days?  I suppose the
main thing that Automake would bring to this party is automatic
dependency generation.  And assuming one cares about nmake in the first
place, I guess that's pretty nice.

> Or is a better alternative to follow the path we have taken with Libtool
> (finally getting MSVC support in) also in Automake, with Peter's patches
> and more?

I'm certainly quite eager to see this in Automake and Libtool.  I
suspect this will hit the sweet spot for a lot of autotools users.

-- 
Braden McDaniel 

Re: advice for pre-generating documentation

[Braden McDaniel]

On Fri, 2010-02-12 at 12:59 +0100, Stefano Lattarini wrote: 
> At Friday 12 February 2010, Braden McDaniel  
> wrote:
> > Actually, EXTRA_DIST can pull in a whole subdirectory.
> Thank you for the information, I didn't know that (or I forgot it).  I 
> guess It's time for me to re-read the Automake documentation.
> > Wildcards work there as well.
> Mmhhh... technically, you are right on this point too (as can be seen 
> by reading any Automake-generated makefile), but I couldn't find 
> anything about this "feature" in the manual...  Are you sure that
> wildcards in EXTRA_DIST are supported "by design" rather than as
> a side-effect of implementation details? In the last case, it could be
> a bad idea to exploit that "feature".

I have no idea.  It's worked that way for a long time.

While in general I agree with the Automake philosophy regarding
wildcards, Doxygen integration is one place where they make a whole lot
of sense.  I hope the Automake maintainers don't decide to break this.

But if they do, we still have dist-hook.

-- 
Braden McDaniel 

Re: advice for pre-generating documentation

[Braden McDaniel]

On Fri, 2010-02-12 at 00:03 +0100, Stefano Lattarini wrote: 
> At Thursday 11 February 2010, Andreas Jellinghaus  
> wrote:
> > Hi,
> Hello Andreas.  I'm by no means an expert on complex Automake usage, but
> maybe I can provide a hint or two.
> > 
> > we generate some docs with doxygen, others with a shell
> > script using wget and xslt to download our wiki and
> > create local html files from that).
> > 
> > that mechanism is currently enabled with "--enable-doc",
> > off by default as it is time-consuming and usualy not
> > wanted.
> > 
> > the problem I have is this:
> > * I want people to checkout svn and compile and test the
> >   software without generating documentation.
> > * if people want the docs, they should be able to create
> >   them too.
> 
> > * if I run "make distcheck", I want the existing documentation
> >   to be included in the tar.gz file.
> Maybe a dist-hook can help here:
>  - http://www.gnu.org/software/automake/manual/html_node/The-dist-Hook.html
> A dist-hook can be especially useful if you don't know in advance the names
> of all the files to be included in the distribution tarball, in which case
> EXTRA_DIST is useless (and if I recall correctly, Doxygen generates *a lot*
> of files when creating HTML output).

Actually, EXTRA_DIST can pull in a whole subdirectory. Wildcards work
there as well.

That doesn't help you with install; but you can add an
install-data-local hook for that.

-- 
Braden McDaniel 

CLASSPATH_ENV warning

[Braden McDaniel]

When using -Wall, I get this warning from automake:

tests/Makefile.am:79: user variable `CLASSPATH_ENV' defined here...
/usr/share/automake-1.11/am/java.am: ... overrides Automake variable 
`CLASSPATH_ENV' defined here
tests/Makefile.am:81:   while processing `dist_noinst_JAVA'

Is this really appropriate?  CLASSPATH_ENV is documented in the manual
as something that is user-settable.

-- 
Braden McDaniel 

Re: suggestions about AC_CONFIG_MACRO_DIR

[Braden McDaniel]

On 4/22/09 2:16 PM, Lorenzo Bettini wrote:

Braden McDaniel wrote:

On 4/22/09 12:13 PM, Lorenzo Bettini wrote:

Braden McDaniel wrote:

On 4/21/09 1:35 PM, Lorenzo Bettini wrote:

Hi

I started adding some m4 macros to my program, that I put in the m4
directory in my sources, and that will be installed during the make
install.

I then added

aclocaldir = $(datadir)/aclocal
aclocal_DATA = ax_boost_base.m4 ax_boost_regex.m4


Unless you're Boost, you shouldn't be installing these.


well, but my library needs boost regex library, so I was planning to
write an autoconf macro that not only searches for my library but also
for boost regex library...


If you really want to do that, you need to change the names of the
files, the macros themselves, and any public shell variables in the
macros so that you do not conflict with versions of these macros
someone else might install.



but in that case, aclocal should get those versions instead of mine,
shouldn't it?


aclocal will get the version that used in configure.ac (or used in a 
macro that's used in configure.ac)... which should be your renamed variant.



But you really should just use pkg-config instead.


I actually use pkg-config for my library; but boost libraries don't come
with a pkg-config .pc file unfortunately :-(

or did you mean something else?


As long as Boost isn't providing pkg-config metadata, you can simply 
refer directly to the Boost libraries you need in -l flags in your .pc 
file's Libs (or Libs.private).


--
Braden McDaniel  e-mail: 
<http://endoframe.com>   Jabber: 

Re: suggestions about AC_CONFIG_MACRO_DIR

[Braden McDaniel]

On 4/22/09 12:13 PM, Lorenzo Bettini wrote:

Braden McDaniel wrote:

On 4/21/09 1:35 PM, Lorenzo Bettini wrote:

Hi

I started adding some m4 macros to my program, that I put in the m4
directory in my sources, and that will be installed during the make
install.

I then added

aclocaldir = $(datadir)/aclocal
aclocal_DATA = ax_boost_base.m4 ax_boost_regex.m4


Unless you're Boost, you shouldn't be installing these.


well, but my library needs boost regex library, so I was planning to
write an autoconf macro that not only searches for my library but also
for boost regex library...


If you really want to do that, you need to change the names of the 
files, the macros themselves, and any public shell variables in the 
macros so that you do not conflict with versions of these macros someone 
else might install.


But you really should just use pkg-config instead.

--
Braden McDaniel  e-mail: 
<http://endoframe.com>   Jabber: 

Re: suggestions about AC_CONFIG_MACRO_DIR

[Braden McDaniel]

On 4/21/09 1:35 PM, Lorenzo Bettini wrote:

Hi

I started adding some m4 macros to my program, that I put in the m4
directory in my sources, and that will be installed during the make
install.

I then added

aclocaldir = $(datadir)/aclocal
aclocal_DATA = ax_boost_base.m4 ax_boost_regex.m4


Unless you're Boost, you shouldn't be installing these.


in the m4/Makefile.am

and

ACLOCAL_AMFLAGS = -I m4


And, BTW, setting ACLOCAL_AMFLAGS as such seems to be sufficient for 
telling recent automake to pull the macros in that directory into the 
distribution.



in the root Makefile.am (together with m4 in subdirs).

Now, if I run autoreconf, it will install the .m4 files related to
libtool in my m4 directory:


[snip]


is it a good thing? Or would it be better to keep these macros in a
different directory? In that case I should pass
AC_CONFIG_MACRO_DIR([other value?]).
What is the most used convention about this?


I put them all in the same place.  I think that's common.

--
Braden McDaniel  e-mail: 
<http://endoframe.com>   Jabber: 

Re: pkg-config, anyone?

[Braden McDaniel]

On Oct 10, 2008, at 2:28 PM, Matěj Týč wrote:


Hello friends,
I would like to inquire whether there is someone here that  
generates .pc
files in his autotools-powered project (presumably a project  
containing

libraries).


The most common way to do it is to process the file with configure/ 
config.status to make any useful substitutions.


I am particulary searching for a manner how to specify the library  
name

in a smart way since libtool can be very creative when decorating the
library name (if you use the -version-number etc. options).


You don't use that information when linking with the library, typically.


Imagine that you would like a library to have different name on each
platform and you would also like to generate and install a .pc file  
for

every one of those platforms. Obviously it would be very helpful if it
was possible using the same .pc.in template.
I have found this guide (http://tinyurl.com/4jkjsb) , but the library
name is specified by hand, which is not auto, right? :-)
Regards,
Matej


The version numbers you see in that example are not libtool library  
version numbers; rather, they are simply part of the library name.


Giving your library a different name on every platform is a bit  
unusual; but you should be able to accomplish it with configure  
substitutions.


Braden

Re: [automake] Dependency question with _LDADD

[Braden McDaniel]

Ralf Wildenhues wrote:

Hi Braden,

* Braden McDaniel wrote on Wed, Aug 27, 2008 at 08:48:45AM CEST:

On Wed, 2008-08-27 at 07:41 +0200, Ralf Wildenhues wrote:

* Michel Briand wrote on Wed, Aug 27, 2008 at 03:19:24AM CEST:

Ralf Wildenhues <[EMAIL PROTECTED]> - Tue, 26 Aug 2008 17:43:13 +0200

Why '-I config -I m4'?  AFAICS you do not use AC_CONFIG_MACRO_DIR([m4])
in configure.ac.  I'd use that, and drop '-I config'.

I do not use the macro you mention.

Please do, though.  When you do, please also add
  ACLOCAL_AMFLAGS = -I m4

to the toplevel Makefile.am.

... which brings up a question I have: Why doesn't AC_CONFIG_MACRO_DIR
eliminate the need for setting ACLOCAL_AMFLAGS as such?


Hmm.  You typically have one AC_CONFIG_MACRO_DIR where for example
'aclocal --install' or 'libtoolize --install' will dump macro files.
However, you can have several places in the tree where you need to
pick up macro files from, with -I paths.


Fair enough; but most don't have more than one such directory. As a 
result, having to point the autotools at this directory in more than one 
place feels redundant.


Is there a reason not to give aclocal invocations a -I flag for the 
AC_CONFIG_MACRO_DIR? ACLOCAL_AMFLAGS could complement this.


--
Braden McDaniel  e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>   Jabber: <[EMAIL PROTECTED]>

Re: [automake] Dependency question with _LDADD

[Braden McDaniel]

On Wed, 2008-08-27 at 07:41 +0200, Ralf Wildenhues wrote:
> * Michel Briand wrote on Wed, Aug 27, 2008 at 03:19:24AM CEST:
> > Ralf Wildenhues <[EMAIL PROTECTED]> - Tue, 26 Aug 2008 17:43:13 +0200

[snip]

> > >Why '-I config -I m4'?  AFAICS you do not use AC_CONFIG_MACRO_DIR([m4])
> > >in configure.ac.  I'd use that, and drop '-I config'.
> > >
> > 
> > I do not use the macro you mention.
> 
> Please do, though.  When you do, please also add
>   ACLOCAL_AMFLAGS = -I m4
> 
> to the toplevel Makefile.am.

... which brings up a question I have: Why doesn't AC_CONFIG_MACRO_DIR
eliminate the need for setting ACLOCAL_AMFLAGS as such?

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

Re: Modifying CFLAGS for 'make distcheck'

[Braden McDaniel]

On Sat, 2008-02-09 at 19:47 +1100, Erik de Castro Lopo wrote:
> Hi all,
> 
> I am a big fan of 'make distcheck' and also a fan of compiling with
> gcc's -Werrror flag. Most of my configure.ac scripts also have a
> --enable-gcc-werror options so that I can use -Werror while developing
> but ship tarballs without it.
> 
> So now I had this great idea. Wouldn't it be great if I could tell
> 'make distcheck' use './configure --enable-gcc-werror'!
> 
> Anyone have a clue on how to do this?

DISTCHECK_CONFIGURE_FLAGS = --enable-gcc-werror

in your top-level Makefile.am.

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

Re: "files left in build directory after distclean" using subdir-objects

[Braden McDaniel]

On Mon, 2007-10-08 at 08:51 +0200, Ralf Wildenhues wrote:

[snip]

> Thanks for the report.  This should be fixed by the change from
> 2007-08-16, which will be in Automake 1.11 and 1.10.1.  If you like,
> you can try CVS Automake to confirm this.

Looks promising. Thanks!

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

Re: "files left in build directory after distclean" using subdir-objects

[Braden McDaniel]

On Sun, 2007-10-07 at 18:06 -0400, Braden McDaniel wrote:
> On Sun, 2007-10-07 at 16:41 -0400, Braden McDaniel wrote:
> 
> [snip]
> 
> > I have successfully configured
> > OpenVRML using the MacPorts toolchain (which it sounds like you might
> > also be using) with the following options:
> > 
> > $ ../configure -C --prefix=$HOME --disable-static --enable-gtk-doc 
> > --with-apple-opengl-framework --with-libjs --disable-mozilla-plugin 
> > CPPFLAGS=-I/opt/local/include LDFLAGS=-L/opt/local/lib BOOST_LIB_SUFFIX=-mt
> 
> Unfortunately, after that, it seems it doesn't build because some of the
> gtkglext configure tests don't work correctly with MacPorts.
> 
> I will work on fixing that.

Fix checked in. However, for some reason AC_PATH_X(TRA) on MacPorts
doesn't set x_includes/X_CFLAGS--even though it apparently needs to. As
a result, you need to configure with "--x-includes=/usr/X11R6/include".

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

Re: "files left in build directory after distclean" using subdir-objects

[Braden McDaniel]

On Sun, 2007-10-07 at 16:41 -0400, Braden McDaniel wrote:

[snip]

> I have successfully configured
> OpenVRML using the MacPorts toolchain (which it sounds like you might
> also be using) with the following options:
> 
> $ ../configure -C --prefix=$HOME --disable-static --enable-gtk-doc 
> --with-apple-opengl-framework --with-libjs --disable-mozilla-plugin 
> CPPFLAGS=-I/opt/local/include LDFLAGS=-L/opt/local/lib BOOST_LIB_SUFFIX=-mt

Unfortunately, after that, it seems it doesn't build because some of the
gtkglext configure tests don't work correctly with MacPorts.

I will work on fixing that.

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

Re: "files left in build directory after distclean" using subdir-objects

[Braden McDaniel]

On Sun, 2007-10-07 at 18:59 +0200, Benoit SIGOURE wrote:
> On Oct 7, 2007, at 7:36 AM, Braden McDaniel wrote:
> 
> > On Sat, 2007-10-06 at 14:18 -0400, Braden McDaniel wrote:
> >
> > [snip]
> >
> >> Might I be tripping over some bug that occurs when the  
> >> subdirectory name
> >> is the same as the built executable?
> >
> > The addition of
> >
> > CLEANFILES = openvrml-xembed/.libs/openvrml-xembed
> >
> > has worked around the problem. Suboptimal, I know, since .libs is an
> > implementation detail of libtool.
> >
> 
> Hello Braden,
> I downloaded OpenVRML 0.16.6 from sourceforge but couldn't get past  
> configure (I'm on OSX and have Boost installed under /opt/local and  
> although your configure script doesn't provide any way to indicate  
> where Boost is, I passed it CPPFLAGS='-I/opt/local/include' and  
> LDFLAGS='-L/opt/local/lib', but it was looking for -lboost_thread,  
> except that it is common to not have libboost_thread.* while having  
> libboost_thread-mt.* -- for instance).

You won't see the problem in the 0.16.6 release, anyway. It is on the
CVS HEAD, though. You will need to comment out the aforementioned
CLEANFILES occurrence in src/Makefile.am in order to observe the
problem.

The solution to the problem you encountered is to set
BOOST_LIB_SUFFIX=-mt at configure time. I have successfully configured
OpenVRML using the MacPorts toolchain (which it sounds like you might
also be using) with the following options:

$ ../configure -C --prefix=$HOME --disable-static --enable-gtk-doc 
--with-apple-opengl-framework --with-libjs --disable-mozilla-plugin 
CPPFLAGS=-I/opt/local/include LDFLAGS=-L/opt/local/lib BOOST_LIB_SUFFIX=-mt

You will need to get gtk-doc, libgnomeui, libglade2, and spidermonkey
from MacPorts if you don't already have them. Also libsdl; or pass
--disable-examples. The spidermonkey dependency can also be suppressed
by passing --disable-script-node-javascript instead of --with-libjs.

> Anyways, would it be possible for you to shrink down the problem to a  
> small configure script and Makefile.am so that others can try to  
> reproduce it easily?

I don't know. Given the fact that this problem has occurred for one
program and not the other, it's not obvious to me what could be
triggering this behavior. As I mentioned, the install location is the
only difference that jumps out at me.

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

Re: "files left in build directory after distclean" using subdir-objects

[Braden McDaniel]

On Sat, 2007-10-06 at 14:18 -0400, Braden McDaniel wrote:

[snip]

> Might I be tripping over some bug that occurs when the subdirectory name
> is the same as the built executable?

The addition of

CLEANFILES = openvrml-xembed/.libs/openvrml-xembed

has worked around the problem. Suboptimal, I know, since .libs is an
implementation detail of libtool.

I was surprised, though, that another binary built by the same Makefile
didn't have the same problem. Like openvrml-xembed, it is built into a
directory with the same name as the binary. The only significant
difference between the two that I can see is that openvrml-xembed is
installed in libexec, while the other program is installed in bin.

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

"files left in build directory after distclean" using subdir-objects

[Braden McDaniel]

src/Makefile.am has the following:

if ENABLE_XEMBED
libexec_PROGRAMS = openvrml-xembed/openvrml-xembed
endif

openvrml_xembed_openvrml_xembed_CPPFLAGS = \
-I$(top_srcdir)/lib/gtkglext \
-I$(top_builddir)/lib/gtkglext \
-I$(top_builddir)/lib/gtkglext/gdk \
-I$(top_builddir)/src/libopenvrml \
-I$(top_srcdir)/src/libopenvrml \
-I$(top_builddir)/src/libopenvrml-gl \
-I$(top_srcdir)/src/libopenvrml-gl \
-I$(mozincludedir) \
-DGTK_DISABLE_DEPRECATED
openvrml_xembed_openvrml_xembed_CXXFLAGS = \
$(PTHREAD_CFLAGS) \
$(GTK_CFLAGS) \
$(GL_CFLAGS)
openvrml_xembed_openvrml_xembed_SOURCES = \
openvrml-xembed/main.cpp \
openvrml-xembed/command_istream.cpp \
openvrml-xembed/plugin_streambuf.cpp \
openvrml-xembed/gtkvrmlbrowser.cpp
openvrml_xembed_openvrml_xembed_LDFLAGS = $(OPENVRML_RPATH) $(GTK_LIBS)
openvrml_xembed_openvrml_xembed_LDADD = \
libopenvrml-gl/libopenvrml-gl.la \
libopenvrml/libopenvrml.la \
$(top_builddir)/lib/gtkglext/gtk/libgtkglext-x11-1.0.la \
$(top_builddir)/lib/gtkglext/gdk/libgdkglext-x11-1.0.la

When I run "make dist", I get:

make[2]: Leaving directory 
`/home/braden/src/openvrml/openvrml.nonrecursive/build/openvrml-0.16.6/_build'
rm -f config.status config.cache config.log configure.lineno 
config.status.lineno
rm -f Makefile
ERROR: files left in build directory after distclean:
./src/openvrml-xembed/.libs/openvrml-xembed
make[1]: *** [distcleancheck] Error 1

I am using Automake 1.10.

Might I be tripping over some bug that occurs when the subdirectory name
is the same as the built executable?

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

Re: parallel make bug with subdir-objects (was: Library locations)

[Braden McDaniel]

On Mon, 2007-08-06 at 08:33 +0200, Ralf Wildenhues wrote:
> Hello Braden,
> 
> * Braden McDaniel wrote on Mon, Aug 06, 2007 at 12:27:48AM CEST:
> > 
> > Related to this, I have observed dependency problems when using
> > "make -j[n > 1]" with a nonrecursive make setup (and on a multiprocessor
> > system). I have not filed a bug report on this because I'm at somewhat
> > of a loss as to how to condense this failure into a useful bug report.
> 
> Post the Makefile.am and post a full 'make -jN' output that shows the
> failure, please.  If you use Automake < 1.10, please update to that and
> see if you can still reproduce the failure.

Sorry for the much-delayed follow-up on this; but I think I've found the
problem here. (And, yes, I'm using Automake 1.10.)

My Makefile.am includes targets for both libraries and programs; and the
latter depend on the former. If I refer to a library dependency relative
to top_builddir, make says it has no rule to build the target. If I
refer to the library relative to builddir, it works fine.

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

Re: Library locations

[Braden McDaniel]

On Mon, 2007-08-06 at 10:53 +1000, Russell Shaw wrote:

[snip]

> However, the shared object that dlopen requires is in a new .libs
> directory:
> 
>modules/System/.libs/system.o
>modules/System/.libs/system.so
>modules/System/.libs/system.so.0
>modules/System/.libs/system.so.0.0.0
> 
> 
> Dlopen fails because it is looking for modules/System/system.so
> When installed, i'll have the install location at:
> 
>/usr/lib/$(pkglibdir)/System/system.so
> 
> 
> Should i just have dlopen look for modules/System/.libs/system.so
> and modules/System/system.so and use the first one that succeeds, or
> is there a cleaner way for avoiding this?

You can use libltdl's ltdlopen instead. libltdl is included with
libtool.

> Also, what's the best way to determine from within the program whether
> it is currently installed or not?

I generally provide environment variables that can be set to search
paths or fully-qualified executables, as appropriate. If such
environment variables aren't set, I default to using programs/libraries
in their installed locations.

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

Re: Library locations

[Braden McDaniel]

On Sun, 2007-08-05 at 23:33 +0200, Ralf Wildenhues wrote:

[snip]

> Then you have subdir-objects set.

I do; I forgot about that.

Related to this, I have observed dependency problems when using
"make -j[n > 1]" with a nonrecursive make setup (and on a multiprocessor
system). I have not filed a bug report on this because I'm at somewhat
of a loss as to how to condense this failure into a useful bug report.
If you're interested in knowing about such failures, any guidance you
could provide here would be appreciated.

I can certainly tar up my source tree and send it to you; though I
appreciate that could be a bit overwhelming.

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

Re: Library locations

[Braden McDaniel]

On Mon, 2007-08-06 at 03:49 +1000, Russell Shaw wrote:
> Hi,
> In automake.am, i have:
> 
>System_LTLIBRARIES = system.la
>system_la_SOURCES = modules/System/system.c
>system_la_LDFLAGS = -module
> 
> This compiles ok. However, it puts system.la in the top level src directory.
> 
> 
> I want it to be like:
> 
>System_LTLIBRARIES = modules/System/system.la
>modules_System_system_la_SOURCES = modules/System/system.c
>modules_System_system_la_LDFLAGS = -module
> 
> 
> That makes "modules/System/system.la" ok, but it still puts
> system.o and system.lo in the top level src directory.

Look again. That's entirely inconsistent with my experience with
automake's (1.10) behavior. The object file generated from the above
should be "modules/System/modules_System_system_la-system.lo".

> That means the program won't work in the uninstalled state,
> because dlopen is looking for system.o as modules/System/system.o.

That seems unlikely. dlopen should be looking for system.so. I don't
imagine it cares about the location of system.o.

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

Re: best aclocal include practice wanted

[Braden McDaniel]

On Sat, 2006-03-04 at 19:52 +0100, Thomas Porschberg wrote:
> what is the recommended way to include project-written m4 macros ?
> 
> I include the macros in /config/m4
> and call in autogen.sh "aclocal -I config/m4"

Set

  ACLOCAL_AMFLAGS = -I config/m4

in your top-level Makefile.am, and just run autoreconf.

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

Re: Built sources always regenerated

[Braden McDaniel]

On Sun, 2006-01-01 at 15:41 -0700, Tom Tromey wrote:
> >>>>> "Braden" == Braden McDaniel <[EMAIL PROTECTED]> writes:
> 
> Braden> Forget about BUILT_SOURCES and *_DEPENDENCIES. The sources I'm 
> building
> Braden> get #include'd by browser.cpp. As such, checking of browser.cpp's
> Braden> dependencies should cause them to get (re)generated, right?
> 
> Braden> But it doesn't. If I remove BUILT_SOURCES, the files don't get
> Braden> generated before browser.cpp gets compiled. Why not?
> 
> Automake dependency tracking information is computed as a side effect
> of compilation.  So, the first time things are compiled, it has no way
> of knowing about dependencies on generated files.

Yeah... I did some more thorough looking into how automake does its
thing and discovered this.

> BUILT_SOURCES is a hack to get around this.  It basically inserts a
> 'make $(BUILT_SOURCES)' before targets like 'all'.  (It would be nice
> to have per-{executable,library} BUILT_SOURCES...)
> 
> I didn't look into this too deeply but I would guess that it is more
> make-related than automake-related.  You can add rules to the
> Makefile.am to help with debugging, eg:
> 
> hack:
> $(MAKE) $(BUILT_SOURCES)
> 
> Then in theory 'make hack' should reproduce the problem you're seeing.

And it does.

> If that doesn't happen then something weird and perhaps
> automake-related is going on.  If it does happen, you can try plain
> old Makefile debugging with 'make -d'.



The problem is that antlr doesn't seem to modify the timestamp when it
regenerates files.

Solved by touching the generated files immediately after antlr runs.



Thanks for your help, gentlemen.

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

Re: Built sources always regenerated

[Braden McDaniel]

Alright, let's back up a bit.

Forget about BUILT_SOURCES and *_DEPENDENCIES. The sources I'm building
get #include'd by browser.cpp. As such, checking of browser.cpp's
dependencies should cause them to get (re)generated, right?

But it doesn't. If I remove BUILT_SOURCES, the files don't get generated
before browser.cpp gets compiled. Why not?

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

Re: Built sources always regenerated

[Braden McDaniel]

On Sun, 2006-01-01 at 11:29 +0100, Stepan Kasal wrote:
> Hello Braden,
> 
> I tried to check out openvrml from sourceforge, but anonymous cvs access
> doesn't seem to work well at the moment.

:-/

> But I was able to see the Makefile.am, and the obvious question is:
> whe creates
>   openvrml/src/libopenvrml/openvrml/Vrml97TokenTypes.txt
> and when?

It's not generated; it's manually created and modified. From my working
copy:

$ stat src/libopenvrml/openvrml/Vrml97TokenTypes.txt
  File: `src/libopenvrml/openvrml/Vrml97TokenTypes.txt'
  Size: 1040Blocks: 16 IO Block: 4096   regular file
Device: fd01h/64769dInode: 19466443Links: 1
Access: (0664/-rw-rw-r--)  Uid: (  500/  braden)   Gid: (  500/  braden)
Access: 2005-12-31 17:03:59.0 -0500
Modify: 2005-06-29 04:34:58.0 -0400
Change: 2005-07-15 04:00:52.0 -0400

> Perhaps you didn't meant to work in directory
>   openvrml/src/libopenvrml/openvrml/
> but in the top level openvrml?

No; I did intend to put things in src/libopenvrml/openvrml.

> Then you would need to use the following:
>   $(top_builddir)/openvrml/Vrml97Parser.hpp
>   $(top_builddir)/openvrml/Vrml97Parser.cpp
>   $(top_srcdir)/openvrml/Vrml97Parser.g
>   $(top_builddir)/openvrml/Vrml97TokenTypes.txt
>   etc.
> 
> Please read about top_builddir, srcdir, and such in the Autoconf manual
> (and also perhaps in the Automake manual).

I know about them. As I mentioned, I'm generating these built sources
into srcdir because I want them to be distributed in the tarball. It's
my understanding that putting them in srcdir is the proper thing in that
case.

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

Re: Built sources always regenerated

[Braden McDaniel]

On Sat, 2005-12-31 at 14:22 +0100, Stepan Kasal wrote:
> Hello,
> 
> On Sat, Dec 31, 2005 at 02:51:30AM -0500, Braden McDaniel wrote:
> > but the behavior is the same: the sources are regenerated every time,
> > regardless of whether the antlr grammar has been modified.
> 
> I can imagine several problems:
> 1) there is a prerequisite which is always refreshed and causes this

I can't see how that could be happening. For instance, here's one of the
rules that generates sources from a grammar:

$(srcdir)/openvrml/Vrml97Parser.hpp 
$(srcdir)/openvrml/Vrml97Parser.cpp: $(srcdir)/openvrml/Vrml97Parser.g 
$(srcdir)/openvrml/Vrml97TokenTypes.txt
$(ANTLR) -o $(srcdir)/openvrml $(srcdir)/openvrml/Vrml97Parser.g

None of the prerequisites are getting updated. In fact, if I issue the
command:

$ make -C src/libopenvrml 
../../../src/libopenvrml/openvrml/Vrml97Parser.cpp

I get:

make: Entering directory 
`/home/braden/src/openvrml/openvrml/build/src/libopenvrml'
make: `../../../src/libopenvrml/openvrml/Vrml97Parser.cpp' is up to 
date.
make: Leaving directory 
`/home/braden/src/openvrml/openvrml/build/src/libopenvrml'

And yet if I then just issue "make", the source gets regenerated.

> 2) If you use non-GNU make, it can may not understand that "./foo.c" and
> "foo.c" is the same file.

I am using GNU make 3.80.

> 3) If you work on a networked drive, the target may have time stamp in the
> future, and make decides to refresh it.

Definitely not the issue.

> I cannot guess more without seeing the makefile.  Could you please post
> (an URL to) a self-contained example?  If you are able to cut some parts
> and make the example smaller, that would definitely help.

The problem Makefile.am is here:


<http://cvs.sourceforge.net/viewcvs.py/openvrml/openvrml/src/libopenvrml/Makefile.am?rev=1.22&view=auto>

Information for checking out the project from CVS is here:

<http://sourceforge.net/cvs/?group_id=7151>

The Makefile.am isn't terribly complex; but I imagine I can come up with
a simple example project if necessary.

> > I have some sources that are generated with antlr. I have custom make
> > rules that generate the sources from the antlr grammar. I have tried
> > listing the generated sources in both BUILT_SOURCES and _DEPENDENCIES,
> 
> Overriding *_DEPENDENCIES is dangerous, it is better to let Automake
> compute it.

Yes; when trying that, I checked to see what was "normally" in
*_DEPENDENCIES and I augmented it.

> The BUILT_SOURCES hack is useful sometimes, but it's better to avoid it.

Using BUILT_SOURCES works marginally worse than *_DEPENDENCIES: with
BUILT_SOURCES, the generated sources are regenerated *twice*:

make[3]: Entering directory 
`/home/braden/src/openvrml/openvrml/build/src/libopenvrml'
/usr/bin/antlr -o ../../../src/libopenvrml/openvrml 
../../../src/libopenvrml/openvrml/Vrml97Parser.g
ANTLR Parser Generator   Version 2.7.4   1989-2004 jGuru.com
/usr/bin/antlr -o ../../../src/libopenvrml/openvrml -glib 
../../../src/libopenvrml/openvrml/Vrml97Parser.g 
../../../src/libopenvrml/openvrml/X3DVrmlParser.g
ANTLR Parser Generator   Version 2.7.4   1989-2004 jGuru.com
make  all-am
make[4]: Entering directory 
`/home/braden/src/openvrml/openvrml/build/src/libopenvrml'
/usr/bin/antlr -o ../../../src/libopenvrml/openvrml 
../../../src/libopenvrml/openvrml/Vrml97Parser.g
ANTLR Parser Generator   Version 2.7.4   1989-2004 jGuru.com
/usr/bin/antlr -o ../../../src/libopenvrml/openvrml -glib 
../../../src/libopenvrml/openvrml/Vrml97Parser.g 
../../../src/libopenvrml/openvrml/X3DVrmlParser.g
ANTLR Parser Generator   Version 2.7.4   1989-2004 jGuru.com
make[4]: Leaving directory 
`/home/braden/src/openvrml/openvrml/build/src/libopenvrml'

> Perhaps you could use a suffix rule
> 
> antlr.c:.
>   custom commands
> 
> and then add the antlr grammar file to *_SOURCES:
> 
> myprog_SOURCES = ... foo.antlr ...

I think the particulars of invoking antlr are such that a suffix rule
won't work.

Could the problem be related to the fact that I'm generating the sources
in $(srcdir)? I'm doing that because I want to distribute them: I don't
want users to have to rebuild them.

Note also that my generated sources do not get listed in *_SOURCES. They
are not compiled individually; rather, they are included by
openvrml/browser.cpp.

> Happy hacking in the New Year!

You too!

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

Built sources always regenerated

[Braden McDaniel]

I have some sources that are generated with antlr. I have custom make
rules that generate the sources from the antlr grammar. I have tried
listing the generated sources in both BUILT_SOURCES and _DEPENDENCIES,
but the behavior is the same: the sources are regenerated every time,
regardless of whether the antlr grammar has been modified.

How can I keep this stuff from being regenerated all the time?

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

Re: multiple configure.ac --> single aclocal.m4

[Braden McDaniel]

Sam Steingold wrote:

I have a large package with many subpackages.
each subpackage has its own configure.ac.
how do I generate aclocal.m4?


[snip]


So: how do I use aclocal.m4 with multiple subpackage configure.in?


Given:

  package/
m4/
Makefile.am
configure.ac
subpackage/
  Makefile.am
  configure.ac

In package/Makefile.am:

  ACLOCAL_AMFLAGS = -I m4

In package/subpackage/Makefile.am:

  ACLOCAL_AMFLAGS = -I ../m4

You shouldn't need to run aclocal directly; if you run autoreconf, it 
should Just Work.


Braden

Re: Installing (everything in) a generated directory

[Braden McDaniel]

On Fri, 2004-11-26 at 08:49 +0100, Alexandre Duret-Lutz wrote:
> >>> "Braden" == Braden McDaniel <[EMAIL PROTECTED]> writes:
> 
> [...]
> 
>  Braden> html: manual/index.html
> 
> (This should be html-local, BTW; try running automake -Wall.)
> 
> [...]
> 
>  Braden> ... then I run into problems in "make install":
> 
>  Braden> Making install in doc
>  Braden> make[2]: Entering directory 
> `/home/braden/src/openvrml/openvrml/BUILD/openvrml-0.14.99/_build/doc'
>  Braden> make[3]: Entering directory 
> `/home/braden/src/openvrml/openvrml/BUILD/openvrml-0.14.99/_build/doc'
>  Braden> make[3]: Nothing to be done for `install-exec-am'.
>  Braden> /usr/bin/doxygen
> 
> There is something wrong in your dependencies if make attempts
> to rebuild the documentation even when it already exists.
> Perhaps Doxyfile is a non-distributed build file?

Argh... That's it. Doxyfile is generated by configure.

>   See the
> distcleancheck node of the manual for some discussion about
> this kind of dependency and a possible workaround.
> 
> [...]
> 
>  Braden> Again, using dist-hook to copy the files instead of listing "manual" 
> in
>  Braden> EXTRA_DIST circumvents this problem.
> 
> Hiding the bug instead of fixing it?  (It's a bug if the
> documentation you distribute is always rebuilt when a user
> attempt a VPATH build.  There is no point in distributing
> the doc if users have to rebuild it anyway.)

Yeah... I probably just need to stop generating Doxyfile. As long as the
docs are built in the srcdir, generating it is really just a minor
convenience for me.

Thanks.

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

Re: Installing (everything in) a generated directory

[Braden McDaniel]

On Thu, 2004-11-25 at 21:10 +0100, Alexandre Duret-Lutz wrote:
> >>> "Braden" == Braden McDaniel <[EMAIL PROTECTED]> writes:
> 
> [...]
>  >> >   EXTRA_DIST = manual
> [...]
>  >> >   html: manual
> [...]
>  >> >   install-data-local: manual installdirs-local
>  >> > $(INSTALL_DATA) ./manual/* $(DESTDIR)$(docdir)/manual
> [...]
>  >> >   manual:
>  >> > $(DOXYGEN)
>  >> > 
>  >> > When "make distcheck" runs "make install", I get this:
> [...]
>  >> >   /usr/bin/install -c -m 644 ./manual/* 
>  >> > 
> /home/bmcdaniel/src/openvrml/openvrml/BUILD/openvrml-0.14.99/_inst/share/doc/openvrml-0.14.99/manual
>  >> >   /usr/bin/install: cannot stat `./manual/*': No such file or directory
>  >> 
>  >> Where are the contents created?  $top_srcdir/manual or
>  >> $top_builddir/manual?
> 
>  Braden> $builddir/manual, which is the same as $top_builddir/doc/manual.
> 
> Because the manual is distributed (EXTRA_DIST) there is a copy
> of it in $(srcdir)/manual at this point of distcheck.  Because
> $(srcdir)/manual exists and we have VPATH=$(srcdir), the `manual'
> dependency of `install-data-local' is satisfied and the manual
> is not recreated (which is undoubtedly what you want, otherwise
> you wouldn't distribute it).
> 
> Hence either the install rule is wrong in assuming that the manual is
> always in the build directory, or the build rule is wrong in building
> the manual in the build directory.
> 
> I suggest you always build distributed files in the source
> directory.  (BTW this is mandatory if you want to support VPATH
> builds with some non-GNU implementation of make.)

Fair enough; I initially had it in the srcdir, but I encountered
problems then. If I do this:

EXTRA_DIST = manual

DISTCLEANFILES = manual/*

html: manual/index.html

installdirs-local:
$(mkinstalldirs) $(DESTDIR)$(docdir)/manual

install-data-local: html installdirs-local
$(INSTALL_DATA) $(srcdir)/manual/* $(DESTDIR)$(docdir)/manual

uninstall-local:
rm -rf $(DESTDIR)$(docdir)/manual

manual/index.html: Doxyfile
$(DOXYGEN)

... then I run into problems in "make install":

Making install in doc
make[2]: Entering directory 
`/home/braden/src/openvrml/openvrml/BUILD/openvrml-0.14.99/_build/doc'
make[3]: Entering directory 
`/home/braden/src/openvrml/openvrml/BUILD/openvrml-0.14.99/_build/doc'
make[3]: Nothing to be done for `install-exec-am'.
/usr/bin/doxygen
GroupDef::insertMembers(): member `node_cast' with class scope 
`openvrml::node' inserted in group scope `nodes'!
Warning: Cannot open file 
/home/braden/src/openvrml/openvrml/BUILD/openvrml-0.14.99/_build/doc/../../doc/manual/doxygen.png
 for writing
Warning: Cannot open file 
/home/braden/src/openvrml/openvrml/BUILD/openvrml-0.14.99/_build/doc/../../doc/manual/Helvetica.ttf
 for writing
Could not open file 
/home/braden/src/openvrml/openvrml/BUILD/openvrml-0.14.99/_build/doc/../../doc/manual/doxygen.css
 for writing
make[3]: *** [manual/index.html] Error 1
make[3]: Leaving directory 
`/home/braden/src/openvrml/openvrml/BUILD/openvrml-0.14.99/_build/doc'
make[2]: *** [install-am] Error 2
make[2]: Leaving directory 
`/home/braden/src/openvrml/openvrml/BUILD/openvrml-0.14.99/_build/doc'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory 
`/home/braden/src/openvrml/openvrml/BUILD/openvrml-0.14.99/_build'
make: *** [distcheck] Error 2

Again, using dist-hook to copy the files instead of listing "manual" in
EXTRA_DIST circumvents this problem.

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

Re: Installing (everything in) a generated directory

[Braden McDaniel]

On Thu, 2004-11-25 at 13:46 -0500, Braden McDaniel wrote:

[snip]

> When I add that, the docs are rebuilt and installed again after "make
> uninstall" (again, as part of "make distcheck"). This fails when the
> attempt is made to copy the files, as apparently _build is no longer
> writable at this point.

I cheated.

Rather than putting "manual" in EXTRA_DIST, I copy the files to $distdir
in dist-hook. That works.

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

Re: Installing (everything in) a generated directory

[Braden McDaniel]

On Thu, 2004-11-25 at 09:37 +0100, Ralf Wildenhues wrote:
> * Braden McDaniel wrote on Thu, Nov 25, 2004 at 01:00:23AM CET:
> > I have the following Makefile.am:
> > 
> >   docdir = $(datadir)/doc/@[EMAIL PROTECTED]@PACKAGE_VERSION@
> > 
> >   EXTRA_DIST = manual
> > 
> >   MAINTAINERCLEANFILES = manual/*
> > 
> >   html: manual
> > 
> >   installdirs-local:
> > $(mkinstalldirs) $(DESTDIR)$(docdir)/manual
> > 
> >   install-data-local: manual installdirs-local
> > $(INSTALL_DATA) ./manual/* $(DESTDIR)$(docdir)/manual
> > 
> >   uninstall-local:
> > rm -rf $(DESTDIR)$(docdir)/manual
> > 
> >   manual:
> > $(DOXYGEN)
> > 
> > When "make distcheck" runs "make install", I get this:
> *snip*
> >   Making install in doc
> >   make[2]: Entering directory 
> > `/home/bmcdaniel/src/openvrml/openvrml/BUILD/openvrml-0.14.99/_build/doc'
> >   make[3]: Entering directory 
> > `/home/bmcdaniel/src/openvrml/openvrml/BUILD/openvrml-0.14.99/_build/doc'
> >   make[3]: Nothing to be done for `install-exec-am'.
> >   /bin/sh ../../mkinstalldirs 
> > /home/bmcdaniel/src/openvrml/openvrml/BUILD/openvrml-0.14.99/_inst/share/doc/openvrml-0.14.99/manual
> >   mkdir -p -- 
> > /home/bmcdaniel/src/openvrml/openvrml/BUILD/openvrml-0.14.99/_inst/share/doc/openvrml-0.14.99/manual
> >   /usr/bin/install -c -m 644 ./manual/* 
> 
> Where did the last argument go?
> 
> > /home/bmcdaniel/src/openvrml/openvrml/BUILD/openvrml-0.14.99/_inst/share/doc/openvrml-0.14.99/manual

It's right there; the line below your comment.

> >   /usr/bin/install: cannot stat `./manual/*': No such file or directory
> 
> Where are the contents created?  $top_srcdir/manual or
> $top_builddir/manual?

$builddir/manual, which is the same as $top_builddir/doc/manual.

>   You need to adapt the install-data-local rule if
> you put docs in the source tree.
> 
> *snip*
> > Since install-data-local depends on manual, I don't understand why 
> > doxygen doesn't get called at that point. Any suggestions?
> 
> Yes, you probably also want
> 
> .PHONY: manual
> 
> so that `make' does not think `manual' is up-to-date already.

When I add that, the docs are rebuilt and installed again after "make
uninstall" (again, as part of "make distcheck"). This fails when the
attempt is made to copy the files, as apparently _build is no longer
writable at this point.

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

Installing (everything in) a generated directory

[Braden McDaniel]

I have the following Makefile.am:
  docdir = $(datadir)/doc/@[EMAIL PROTECTED]@PACKAGE_VERSION@
  EXTRA_DIST = manual
  MAINTAINERCLEANFILES = manual/*
  html: manual
  installdirs-local:
$(mkinstalldirs) $(DESTDIR)$(docdir)/manual
  install-data-local: manual installdirs-local
$(INSTALL_DATA) ./manual/* $(DESTDIR)$(docdir)/manual
  uninstall-local:
rm -rf $(DESTDIR)$(docdir)/manual
  manual:
$(DOXYGEN)
When "make distcheck" runs "make install", I get this:
  make[1]: Entering directory 
`/home/bmcdaniel/src/openvrml/openvrml/BUILD/openvrml-0.14.99/_build'
  Making install in doc
  make[2]: Entering directory 
`/home/bmcdaniel/src/openvrml/openvrml/BUILD/openvrml-0.14.99/_build/doc'
  make[3]: Entering directory 
`/home/bmcdaniel/src/openvrml/openvrml/BUILD/openvrml-0.14.99/_build/doc'
  make[3]: Nothing to be done for `install-exec-am'.
  /bin/sh ../../mkinstalldirs 
/home/bmcdaniel/src/openvrml/openvrml/BUILD/openvrml-0.14.99/_inst/share/doc/openvrml-0.14.99/manual
  mkdir -p -- 
/home/bmcdaniel/src/openvrml/openvrml/BUILD/openvrml-0.14.99/_inst/share/doc/openvrml-0.14.99/manual
  /usr/bin/install -c -m 644 ./manual/* 
/home/bmcdaniel/src/openvrml/openvrml/BUILD/openvrml-0.14.99/_inst/share/doc/openvrml-0.14.99/manual
  /usr/bin/install: cannot stat `./manual/*': No such file or directory
  make[3]: *** [install-data-local] Error 1
  make[3]: Leaving directory 
`/home/bmcdaniel/src/openvrml/openvrml/BUILD/openvrml-0.14.99/_build/doc'
  make[2]: *** [install-am] Error 2
  make[2]: Leaving directory 
`/home/bmcdaniel/src/openvrml/openvrml/BUILD/openvrml-0.14.99/_build/doc'
  make[1]: *** [install-recursive] Error 1
  make[1]: Leaving directory 
`/home/bmcdaniel/src/openvrml/openvrml/BUILD/openvrml-0.14.99/_build'
  make: *** [distcheck] Error 2

Since install-data-local depends on manual, I don't understand why 
doxygen doesn't get called at that point. Any suggestions?

--
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

Re: Disabling optimization

[Braden McDaniel]

On Thu, 2004-11-18 at 14:04 +0100, Stepan Kasal wrote:

[snip]

> But my question was whether there was a reason for setting the variable
> _after_ AC_PROG_CXX, as the original suggestion proposed.

In retrospect, I can't think of one.

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

Re: Disabling optimization

[Braden McDaniel]

On Wed, 2004-11-17 at 18:48 -0500, Jonathan wrote:
> My autoconf/automake project is optimizing by default with "-g -O2". 
> Unfortunately, we have verified that this is causing a run-time error
> by overriding CXXFLAGS in Makefile.am with just "-g".  With the "-O2"
> flag removed, everything works great.
> 
> I have been trying to find out where this "-O2" is coming from so I
> can disable it at the configure.ac level, but my attempts have been
> fruitless.

"-g -O2" is what AC_PROG_CC/AC_PROG_CXX sets CFLAGS/CXXFLAGS to if it
isn't already set to something.

> How do I disable the "-O2" flag in the most portable way possible?

I would do something like this (in configure.ac):

if test -n "${CXXFLAGS}"; then
  user_set_cxxflags=yes
fi
AC_PROG_CXX
if test X$user_set_cxxflags != Xyes; then
  CXXFLAGS="-g"
fi

Really you should probably be a little more clever and also check to see
if the compiler in use is the one you have a problem with. But this
approach allows someone who really *wants* to use -O2 (to experiment,
perhaps) to do so.

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

"files left in build directory after distclean"

[Braden McDaniel]

When running "make distcheck", I get:

ERROR: files left in build directory after distclean:
./lib/antlr/GNUmakefile
./lib/antlr/antlr/GNUmakefile
./lib/antlr/src/GNUmakefile

What's going on here? Aren't these files that automake should "know"
about and deal with appropriately? I'm using automake 1.7.7.

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

Re: Installing from install-data-local

[Braden McDaniel]

On Sun, 2003-09-28 at 13:34, Alexandre Duret-Lutz wrote:
> >>> "Braden" == Braden McDaniel <[EMAIL PROTECTED]> writes:
> 
>  Braden> I have this rule in my Makefile.am:
>  Braden> install-data-local:
>  Braden>$(mkinstalldirs) $(docdir)/manual
>  Braden>$(INSTALL_DATA) $(srcdir)/manual/* $(docdir)/manual
> 
>  Braden> This breaks the "distcheck" target; because apparently
>  Braden> distcheck's _inst directory is not writable when this
>  Braden> rule is run.
> [...]
>  Braden> Why is _inst not writable? 
> 
> This allows distcheck to catch user rules that do not honor $(DESTDIR).

So it does. Thanks.

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

Installing from install-data-local

[Braden McDaniel]

I have this rule in my Makefile.am:

install-data-local:
$(mkinstalldirs) $(docdir)/manual
$(INSTALL_DATA) $(srcdir)/manual/* $(docdir)/manual

This breaks the "distcheck" target; because apparently distcheck's _inst
directory is not writable when this rule is run.

mkdir -p -- 
/home/braden/src/openvrml/openvrml/BUILD/openvrml-0.13.99/_inst/share/doc/openvrml-0.13.99/manual
mkdir: cannot create directory 
`/home/braden/src/openvrml/openvrml/BUILD/openvrml-0.13.99/_inst/share/doc/openvrml-0.13.99/manual':
 Permission denied

Why is _inst not writable? Is there a correct way of doing what I'm
trying to do? (Explicity listing all the files in the "manual"
subdirectory is impractical; that is why I have not used the DATA
primary.)

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

Re: Optimisation across source files.

[Braden McDaniel]

On Fri, 04 Apr 2003 21:44:07 +0100, Dr. David Kirkby wrote:

> Hi,
>   I don't know about other programmers, but I tend to put one function
> in each source file. So function foo() goes into foo.c. Looking
> carefully at the documentation for Sun's c compiler, I not that the
> optimiser will only try to inline functions in the same source file,
> so my method of one source function/file, effectively stops the
> optimiser from inlining any functions. However, Sun's compiler has an
> option, -xcrossfile which will attempt to inline functions across
> files. Great one thinks, just add that option.

[snip]

In general, if you want functions inlined in multiple translation units,
the functions should be defined in a header file. Obviously, these
functions must have internal linkage, so you wind up with a "private" (or,
not to be installed) header.

If you have functions with external linkage that you want to be inlined,
then they will need to be in the same file. But it is unusual to want
this. In general, in C, public "functions" that should be inlined get cast
as macros.
 
> Certainly reading the Sun compiler manual has made me re-think my
> practice of putting each function (except very small ones) in their
> own source file. 

The usual recommendation is "one externally linked symbol definition per
translation unit". This is derived from the tendency of linkers to
discriminate per object file rather than per symbol.

(I'll note that I regularly violate this recommendation and define in the
same translation unit closely related things that will invariably be used
together. This practice has the side effect of letting me avoid putting
too much stuff in private headers.)

> It does not seem unreasonable for automake to keep a list of compiler
> options like this (even if there is one per compiler), and if detected
> build the makefile such that changes in any source file cause all
> those files that are every linked with that file to be rebuilt, even
> if their source has not changed.

I think that since there is a mechanism for achieving this that works
reliably across compilers, there isn't a need for automake to support the
compiler-specific mechanism. It sounds to me like this option for the Sun
compiler creates the same coupling that would be present if the
definitions had been in the same translation unit to begin with.

Braden

Re: CXXFLAGS and linking

[Braden McDaniel]

Quoting Alexandre Duret-Lutz <[EMAIL PROTECTED]>:

> >>> "Braden" == Braden McDaniel <[EMAIL PROTECTED]> writes:
> 
>  Braden> GNU make doesn't agree.
> 
> I hear you, but that no reason: Automake follows the GNU Coding
> Standards in this case.

I've reviewed 7.2 in the GNU Coding Standards, and it's not clear to me what
you're referring to. Where exactly should I be looking?

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

Re: CXXFLAGS and linking

[Braden McDaniel]

On Fri, 2003-01-24 at 03:47, Alexandre Duret-Lutz wrote:
> >>> "William" == William S Fulton <[EMAIL PROTECTED]> writes:
> 
>  William> I see that CXXFLAGS and AM_CXXFLAGS gets passed to the linker
>  William> ($CXXLINK). 
> 
> CXXLINK calls the compiler, so we ought to pass these flags as they
> may affect the way the compiler calls the linker in the end.
> For instance the compiler might pass on additional objects to
> link based on the presence of flags like `-g', `-pg' or
> `-pthread'.

GNU make doesn't agree. Its default linking action invokes cc, but does
not pass CFLAGS.

I'd suggest that the flags you mention are linker flags for the reason
that they should be passed to the program invoked to handle the linking
step. Whether that program delegates responsibility to another program
doesn't matter from the perspective of the makefile.

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

Re: CXXFLAGS and linking

[Braden McDaniel]

Quoting William S Fulton <[EMAIL PROTECTED]>:

> I see that CXXFLAGS and AM_CXXFLAGS gets passed to the linker
> ($CXXLINK). This doesn't seem correct as the C++ flags aren't
> necessarily appropriate for linking. This isn't consistent with the
> per-program _CXXFLAGS which do not get passed to the linker. Is this
> all as intended?

I agree with you. I'll also note that GNU make doesn't use CFLAGS when linking
with its default action.

Certainly either way, there's an inconsistency here that should be addressed.

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

Re: configure and intel's C++: inappropriate flags -MT -MD -MP -MF

[Braden McDaniel]

On Fri, 2002-12-20 at 15:17, Alexandre Duret-Lutz wrote:
> >>> "Markus" == Markus Werle <[EMAIL PROTECTED]> writes:
> 
>  Markus> Hi!
>  Markus> I have a problem with the latest autotools:
> 
>  Markus> From somewhere behind the scenes automake/autoconf
>  Markus> decides to insert the following options to the compiler
>  Markus> flags; -MT -MD -MP -MF
> 
> depcomp adds these options, and ./configure makes the decision
> based on the compiler found (or that you specified).
> 
> ./configure prints something like `checking dependency style of XXX'
> at this point.
> 
>  Markus> these are not recognized, say ignored ith annoying warnings by
>  Markus> intel's C++ 7.0. Any idea how to remove these via
>  Markus> configure.in or Makefile.am?
> 
> Maybe your are not setting the compiler early enough?  Since
> ./configure decides which flags to use it must know the
> compiler.  Therefore you should run
> 
>   ./configure CC=mycc; make
> 
> not
> 
>   ./configure; make CC=mycc

I've observed this problem, too; and, yes, I'm configuring with CC set.

However, I'm using autoconf 2.53/automake 1.6.3.

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

Re: Using gcj to create .class files

[Braden McDaniel]

On Thu, 2002-10-24 at 18:02, Tom Tromey wrote:
> >>>>> "Braden" == Braden McDaniel <[EMAIL PROTECTED]> writes:
> 
> >> JAVAC = gcj -C
> 
> Braden> I thought of that, but thought there might be something less
> Braden> subtle.  Perhaps this should be done by the AM_PROG_GCJ macro?
> 
> This is actually sort of a standard approach.
> AC_PROG_CC looks at the CC environment variable.

Good point. But if CC isn't set, AC_PROG_CC sets it to something. My
point being that it would be nice if there were a standard 

> As I recall AM_PROG_GCJ is only useful for compiling java to object
> code.

Yes, I realize now I want something else. And I see the autoconf macro
archive has some candidates. But given that automake uses JAVAC, might
it be appropriate for it to include a macro along the lines of
AM_PROG_JAVAC?

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

Re: Conditionally compiling Java

[Braden McDaniel]

On Wed, 2002-06-12 at 03:15, Alexandre Duret-Lutz wrote:
> >>> "Braden" == Braden McDaniel <[EMAIL PROTECTED]> writes:
> 
> [...]
> 
>  Braden> when I try to use the CVS version of automake, 
> 
> CVS HEAD = future Automake 1.7
> CVS branch-1-6 = upcoming Automake 1.6.2

Well that makes a difference. I don't see the AC_CONFIG_HEADERS problem
in the 1.6 branch.

And the patch appears to work. Thanks.

>  Braden> I get an error from autoheader:
> 
>  Braden> autoheader: error: AC_CONFIG_HEADERS not found in configure.ac
> 
> When does this happen?  I mean, is autoheader run by you or by
> the Makefile?

By me.

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

Re: Conditionally compiling Java

[Braden McDaniel]

On Tue, 2002-06-11 at 13:08, Alexandre Duret-Lutz wrote:
> >>> "Braden" == Braden McDaniel <[EMAIL PROTECTED]> writes:
> 
> [...]
> 
>  Braden> if WITH_JDK
>  Braden> noinst_JAVA = MyClass1.java MyClass2.java
>  Braden> endif
> 
>  Braden> Works if WITH_JDK is true; but if WITH_JDK is false,
>  Braden> javac still gets called, but with no source file
>  Braden> arguments. 
> 
> Could you try this patch?

Looks promising; however, when I try to use the CVS version of automake,
I get an error from autoheader:

  autoheader: error: AC_CONFIG_HEADERS not found in configure.ac

I am in fact using the macro AM_CONFIG_HEADER, but changing to
AC_CONFIG_HEADERS has no effect. Yeah, I know: autoheader comes with
autoconf, not automake. So, any idea what might be triggering this?

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

Re: Conditionally compiling Java

[Braden McDaniel]

On Tue, 2002-06-11 at 04:04, Alexandre Duret-Lutz wrote:
> >>> "Braden" == Braden McDaniel <[EMAIL PROTECTED]> writes:
> 
>  Braden> I'm trying to conditionally compile some Java sources
>  Braden> (with javac) using an Automake conditional:
> 
>  Braden> JAVAROOT = $(top_builddir)/java
> 
>  Braden> JAVA_FILES = MyClass1.java MyClass2.java
> 
>  Braden> if WITH_JDK
>  Braden> noinst_JAVA = $(JAVA_FILES)
>  Braden> endif
> 
>  Braden> EXTRA_DIST = $(JAVA_FILES)
> 
>  Braden> I am having trouble when the condition is false. If
>  Braden> JAVAROOT is defined outside the conditional (as above),
>  Braden> I get this error:
> 
>  Braden> 
>CLASSPATH=../../../java:../../../../java/vrml/field/../../../java:$CLASSPATH  -d 
>../../../java \
>  Braden> /bin/sh: -d: command not found
> 
> I can't reproduce this.  Have you overridden $(JAVAC) somewhere?  

Er, yes. I have this in configure.ac:

  AC_PATH_PROG(JAVAC, javac)

> Here is the test case I've used:
> 
> #! /bin/sh
> 
> # Make sure conditional Java works.
> # Report from Braden McDaniel.
> 
> required=gcj
> . $srcdir/defs || exit 1

Sorry I wasn't clear; I'm trying to use javac from the Sun JDK, not gcj.

I tried changing to

  AC_PATH_PROG(JDK_JAVAC, javac)

I never use $(JDK_JAVAC) other than to test that the variable is
non-empty. And this in my Makefile.am:

  JAVAROOT = $(top_builddir)/java
  
  if WITH_JDK
  noinst_JAVA = MyClass1.java MyClass2.java
  endif

Works if WITH_JDK is true; but if WITH_JDK is false, javac still gets
called, but with no source file arguments. I don't want this to happen
since someone may have configured --without-jdk because they don't have
it on their system.

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

Conditionally compiling Java

[Braden McDaniel]

I'm trying to conditionally compile some Java sources (with javac) using
an Automake conditional:

JAVAROOT = $(top_builddir)/java

JAVA_FILES = MyClass1.java MyClass2.java

if WITH_JDK
noinst_JAVA = $(JAVA_FILES)
endif

EXTRA_DIST = $(JAVA_FILES)

I am having trouble when the condition is false. If JAVAROOT is defined
outside the conditional (as above), I get this error:

CLASSPATH=../../../java:../../../../java/vrml/field/../../../java:$CLASSPATH  -d 
../../../java \

/bin/sh: -d: command not found

If the JAVAROOT definition is moved inside the conditional, I get this
error:

java/vrml/Makefile.am:10: JAVAROOT was already defined in condition WITH_JDK_TRUE, 
which is implied by condition TRUE

  JAVAROOT (User, where = java/vrml/Makefile.am:10) =
  {
WITH_JDK_TRUE => $(top_builddir)/java
  }

What to do?

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

Re: RPM targets for make dist?

[Braden McDaniel]

On Thu, 2001-11-01 at 13:14, Simon Perkins wrote:
> Hi,
> 
> Are there any plans to introduce the ability to generate RPMs using automake?
> Perhaps as an option to 'make dist'? What about the solaris packages format?
> 
> If people have Makefile.am files they've hacked by hand to do this, I'd also be
> interesting in some pointers...

Why bother? Just use dist-hook to include your specfile in the tarball.
Once you have a tarball with a specfile in it, making an RPM is a simple
as

rpm -tb tarball.tar.gz

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

Re: Generated headers that don't get installed

[Braden McDaniel]

On Tue, 2001-10-16 at 14:16, Raja R Harinath wrote:
> Braden McDaniel <[EMAIL PROTECTED]> writes:
> > So I tried nodist_noinst_HEADERS. This had the unexpected effect of
> > installing the headers in the root directory!
> 
> That seems to be a bug in automake.  Can you file a bug report?

Yup. Anyone have any ideas for a workaround in the meantime?

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

Generated headers that don't get installed

[Braden McDaniel]

I have some generated headers that should not be installed, and should
not be included in the distribution of my package.

BUILT_SOURCES doesn't work because these headers have dependecies in
SUBDIRS, and automake wants to built BUILT_SOURCES before building
SUBDIRS.

noinst_HEADERS keeps them from being installed, but they wind up in the
distribution.

So I tried nodist_noinst_HEADERS. This had the unexpected effect of
installing the headers in the root directory!

Any ideas for a way to do what I want here?

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
<http://endoframe.com>Jabber: <[EMAIL PROTECTED]>

Re: More fun with BUILT_SOURCES

[Braden McDaniel]

On 25 Nov 2000, Tom Tromey wrote:

> >>>>> "Braden" == Braden McDaniel <[EMAIL PROTECTED]> writes:
>
> >> > I realize that BUILT_SOURCES is known to be problematic, but I haven't
> >> > found any other solution. Any suggestions?
>
> >> Add explicit dependencies on it.  There's no other way to ensure it's
> >> generated.  BUILT_SOURCES used to work only with GNU make.
>
> Braden> Each source file for my library depends on the generated
> Braden> header, directly or indirectly. Is it possible for me to add
> Braden> explicit dependencies *and* keep the libfoo_la_SOURCES
> Braden> variable? I'm trying to hang on to all of automake's benefits
> Braden> that I possibly can.
>
> You should be able to do that.
>
> I'd really like to find a better solution for the built files
> problem.  This is currently too hard to do in automake.

I ended up doing this:

  $(libfoo_la_OBJECTS): mybuiltheader.h

-- 
Braden N. McDaniel  e-mail: [EMAIL PROTECTED]
<http://endoframe.com>  Jabber: [EMAIL PROTECTED]

Re: More fun with BUILT_SOURCES

[Braden McDaniel]

On 14 Nov 2000, Alexandre Oliva wrote:

> On Nov 14, 2000, Braden McDaniel <[EMAIL PROTECTED]> wrote:
> 
> > I realize that BUILT_SOURCES is known to be problematic, but I haven't
> > found any other solution. Any suggestions?
> 
> Add explicit dependencies on it.  There's no other way to ensure it's
> generated.  BUILT_SOURCES used to work only with GNU make.

Each source file for my library depends on the generated header, directly
or indirectly. Is it possible for me to add explicit dependencies *and*
keep the libfoo_la_SOURCES variable? I'm trying to hang on to all of
automake's benefits that I possibly can.

-- 
Braden N. McDaniel  e-mail: [EMAIL PROTECTED]
<http://www.endoframe.com>  Jabber: [EMAIL PROTECTED]

More fun with BUILT_SOURCES

[Braden McDaniel]

I have an automake script of the following form:

PUBLIC_HFILES = file1.h file2.h
PRIVATE_HFILES = file3.h file4.h
BUILT_SOURCES = file1.h

file1.h: deps
generate file1.h from deps

if INSTALL_PUBLIC_HFILES
include_HEADERS = $(PUBLIC_HFILES)
noinst_HEADERS = $(PRIVATE_HFILES)
else
noinst_HEADERS = $(PUBLIC_HFILES) $(PRIVATE_HFILES)
endif

The problem is that the generated header file (file1.h) never gets
generated. If file1.h occurs directly in one of the *_HEADERS variables,
there is no problem.

I realize that BUILT_SOURCES is known to be problematic, but I haven't
found any other solution. Any suggestions?

-- 
Braden N. McDaniel  e-mail: [EMAIL PROTECTED]
  Jabber: [EMAIL PROTECTED]

Pre-uninstall

[Braden McDaniel]

The uninstall-local target gets executed after the files are deleted. Is
there a target that is executed by uninstall *before* the files get
deleted?

-- 
Braden N. McDaniel  e-mail: [EMAIL PROTECTED]
  Jabber: [EMAIL PROTECTED]