Re: passing flags to C compiler but not to C++ compiler

[Robert Boehne]

On 07/27/13 16:26, Vincent Torri wrote:

On Sat, Jul 27, 2013 at 10:24 PM, Robert Boehne robe...@trdlnk.com wrote:


On 07/27/13 00:32, Vincent Torri wrote:

hello

in my sources, i have both C and C++ files. Something like

my_lib_la_SOURCES = foo.c foo.cpp

I want to pass, for example, -Wdeclaration-after-statement to gcc. Hence,
when compiling foo.cpp, i have the warning :

cc1plus.exe: warning: command line option '-Wdeclaration-after-statement'
is valid for C/ObjC but not for C++

How can I remove this warning when compiling c++ files ?

thank you

Vincent Torri


I misread - for C and not C++ you should set CFLAGS

./configure CFLAGS=-g -O2 -Wdeclaration-after-statement CXXFLAGS=-g -O2

it will still not work as $(CFLAGS) will be passed to the compilation
of the c++ source file

Vincent Torri


Are you saying you've tried it?  That's not my understanding of how Automake
(or GNU Make) works.  Unless the project has overridden the default
use for these variables, that's how it's supposed to work, and
this problem is an example of why.

This is the relevant section of the manual:

http://www.gnu.org/software/automake/manual/automake.html#Standard-Configuration-Variables


for example.  If you want to pass something to the preprocessor,
it's used by both C and C++, use CPPFLAGS
CPPFLAGS=-DSYMBOL=value -I/path/to/headers

You can set them in the environment, but if you use the syntax where it's after
the configure in the command, those settings will be saved in config.log
so you can see what they were set to when you built.

HTH,

Robert Boehne

Re: passing flags to C compiler but not to C++ compiler

[Robert Boehne]

On 07/29/13 10:55, Vincent Torri wrote:

On Mon, Jul 29, 2013 at 5:17 PM, Robert Boehne robe...@trdlnk.com wrote:

On 07/27/13 16:26, Vincent Torri wrote:

On Sat, Jul 27, 2013 at 10:24 PM, Robert Boehne robe...@trdlnk.com
wrote:


On 07/27/13 00:32, Vincent Torri wrote:

hello

in my sources, i have both C and C++ files. Something like

my_lib_la_SOURCES = foo.c foo.cpp

I want to pass, for example, -Wdeclaration-after-statement to gcc.
Hence,
when compiling foo.cpp, i have the warning :

cc1plus.exe: warning: command line option
'-Wdeclaration-after-statement'
is valid for C/ObjC but not for C++

How can I remove this warning when compiling c++ files ?

thank you

Vincent Torri


I misread - for C and not C++ you should set CFLAGS

./configure CFLAGS=-g -O2 -Wdeclaration-after-statement CXXFLAGS=-g
-O2

it will still not work as $(CFLAGS) will be passed to the compilation
of the c++ source file

Vincent Torri


Are you saying you've tried it?

1) yes i tried it

2) the fact that I have the warning proves that CFLAGS is passed to
the C++ compiler...

Vincent Torri



  That's not my understanding of how Automake
(or GNU Make) works.  Unless the project has overridden the default
use for these variables, that's how it's supposed to work, and
this problem is an example of why.

This is the relevant section of the manual:

http://www.gnu.org/software/automake/manual/automake.html#Standard-Configuration-Variables




Then that would be a bug, and you should post enough information
that it can be reproduced, like a tarball of your sources and which 
version you're using.

Re: passing flags to C compiler but not to C++ compiler

[Robert Boehne]

On 07/27/13 00:32, Vincent Torri wrote:

hello

in my sources, i have both C and C++ files. Something like

my_lib_la_SOURCES = foo.c foo.cpp

I want to pass, for example, -Wdeclaration-after-statement to gcc. Hence,
when compiling foo.cpp, i have the warning :

cc1plus.exe: warning: command line option '-Wdeclaration-after-statement'
is valid for C/ObjC but not for C++

How can I remove this warning when compiling c++ files ?

thank you

Vincent Torri


I misread - for C and not C++ you should set CFLAGS

./configure CFLAGS=-g -O2 -Wdeclaration-after-statement CXXFLAGS=-g -O2

for example.  If you want to pass something to the preprocessor,
it's used by both C and C++, use CPPFLAGS
CPPFLAGS=-DSYMBOL=value -I/path/to/headers

You can set them in the environment, but if you use the syntax where 
it's after

the configure in the command, those settings will be saved in config.log
so you can see what they were set to when you built.

HTH,

Robert Boehne

Re: passing flags to C compiler but not to C++ compiler

[Robert Boehne]

You add that flag to CXXFLAGS on the configure command line.

 configure CXXFLAGS=-Wdeclaration-after-statement

Along with any other options you need.


Vincent Torri vincent.to...@gmail.com wrote:
hello

in my sources, i have both C and C++ files. Something like

my_lib_la_SOURCES = foo.c foo.cpp

I want to pass, for example, -Wdeclaration-after-statement to gcc.
Hence,
when compiling foo.cpp, i have the warning :

cc1plus.exe: warning: command line option
'-Wdeclaration-after-statement'
is valid for C/ObjC but not for C++

How can I remove this warning when compiling c++ files ?

thank you

Vincent Torri

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: libtool libraries requiring other libraries

[Robert Boehne]

Steffen,

I would suggest asking questions about Libtool on a libtool mailing list.

That said - It looks to me like you're not *using* libtool to do your 
linking.

Libtool's la files contain all the dependencies that a library needs.
This is a big help when using static archives because they need
to have everything listed in the proper order on the link line.
If you add

LT_INIT

to configure.ac your problem should go away.

HTH,

Robert Boehne

On 07/16/13 09:56, Steffen Sledz wrote:

Sorry, if this is a faq, but i didn't found a clear answer searching around.

Given situation: We have a library called e.g. libfoo which uses e.g. mq_open 
from librt. Than we have a program e.g. called progbar which requires libfoo 
(and therefor also librt).

Our current solution looks like this, but it does not work, because linking 
progbar is missing the -lrt option.

progbar/configure.ac:
- snip -
...
AC_CHECK_LIB([rt], [mq_open], [], [ AC_MSG_ERROR([*** Could not find librt 
***]) ])
...
if test -n $with_libfoo_path ; then
   FOO_LDFLAGS=-L$with_libfoo_path/lib -lfoo
   FOO_CPPFLAGS=-I$with_libfoo_path/include
else
   AC_CHECK_LIB([foo], [foo_init], [], [ AC_MSG_ERROR([*** Could not find 
libfoo, use --with-libfoo-path option ***]) ], [-lrt])
fi
AC_SUBST(FOO_LDFLAGS)
AC_SUBST(FOO_CPPFLAGS)
...
- snap -

progbar/src/Makefile.am:
- snip -
bin_PROGRAM = progbar
...
progbar_CPPFLAGS = $(FOO_CPPFLAGS)
progbar_LDFLAGS = $(FOO_LDFLAGS)
...
- snap -

Where do we have to make which checks?

Do we need a check for librt in the libfoo package?

Do we have to mention the librt link option somewhere in the progbar package?

Thx for any help,
Steffen

PS: FUP set to autoc...@gnu.org

Re: install-strip variant that strips then installs?

[Robert Boehne]

Library paths are hard coded at link time.  For that reason, on some platforms 
Libtool relinks binaries during install.  Because prefix et. al. can be set 
at make time, stripping has to be done on the installed binary because it may 
not exist until then.

So strip before install would not be portable.

HTH,

Robert Boehne


Gavin Smith gavinsmith0...@gmail.com wrote:

On Tue, May 7, 2013 at 5:12 PM, Rhys Ulerich rhys.uler...@gmail.com
wrote:
 I gather that 'make install-strip' installs and then strips binaries.
 Is there some variant that reverses the order?  If not, any
 recommendations for how to write one in an Automake-compliant manner?

 My unstripped binaries are absurdly large and my installation
 directory is NFS-mounted.  So I get to pay lots of network overhead
to
 install what eventually becomes O(100MB) of binaries because the
 unstripped copy is O(1.5GB).

 Thanks,
 Rhys


This seems like a good idea to me. Is there any reason why the order
couldn't be reversed?

The only problem I can think of is that make install-strip isn't
expected to modify the binaries in the build directory, and the user
might conceivably be relying on them being unstripped (for some
obscure reason). If that could be a problem, perhaps a solution is to
have a separate strip rule which could be run.

You could try writing a rule yourself in your Makefile.am to strip the
binaries. You could use the bin_PROGRAMS make variable that is set in
the output Makefile.

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: problem with AM_PATH_PYTHON

[Robert Boehne]

On 10/26/12 09:04, Stefano Lattarini wrote:

Hi Václav, sorry for the delay.

On 10/15/2012 09:07 PM, Václav Zeman wrote:

Hi.

I am having a problem with AM_PATH_PYTHON. I have this in my configure.ac:


AS_IF([test x$with_python = xyes],
   [AM_PATH_PYTHON([2.3], [:], [:])
AX_SWIG_PYTHON
AC_CONFIG_FILES([swig/python/Makefile])])


The problem is that when I am cross compiling it ignores the if-block
and puts the code of AM_PATH_PYTHON outside. The configure process then
breaks like this:


configure: WARNING: using cross tools not prefixed with host triplet
checking pkg-config is at least version 0.9.0... yes
checking for python... /usr/bin/python
checking for a version of Python = '2.1.0'... yes
checking for the distutils Python package... yes
checking for Python include path... -I/usr/include/python2.7
checking for Python library path... -L/usr/lib -lpython2.7
checking for Python site-packages path... /usr/lib/python2.7/dist-packages
checking python extra libraries... -lssl -lcrypto  -lssl -lcrypto \
   -L/usr/lib -lz -lpthread -ldl  -lutil
checking python extra linking flags... -Xlinker -export-dynamic -Wl,-O1 \
   -Wl,-Bsymbolic-functions
checking consistency of all components of python development environment... no
configure: error: in /home/wilx/log4cplus-bzr/work-trunk/objdir-mips-linux-gnu:
configure: error:
   Could not link test program to Python. Maybe the main Python library has been
   installed in some non-standard library path. If so, pass it to configure,
   via the LDFLAGS environment variable.
   Example: ./configure LDFLAGS=-L/usr/non-standard-path/python/lib


This doesn't look like output from the Automake-provided AM_PATH_PYTHON
macro...  Could you please post your config.log, configure and aclocal.m4
files (all compressed, please), as well as the exact command you've used
to generate them?  Maybe we'll have a better chance to understand what is
going on ...

Thanks,
   Stefano


That is because it's coming from this line in AX_SWIG_PYTHON in the 
autoconf-archive.


AC_REQUIRE([AX_PYTHON_DEVEL])

Re: Cannot Create Executables (configure and -fPIC/-pic)

[Robert Boehne]

Jeffrey,

If you look at config.log it will show you the test program that it was 
attempting

to compile, and what errors that attempt generated.  It seems like your
compiler doesn't like -fPIC -pic and it has little to do with autotools.

HTH,

Robert

On 08/21/12 17:06, Jeffrey Walton wrote:

Hi All,

When I try and run configure with -fPIC -pic (as opposed to -fPIE
-pie), I receive C compiler cannot create executables.

./configure CFLAGS=-Wall -Wextra -Wconversion -fPIC -pic
-Wno-unused-parameter -Wformat=2 -Wformat-security
-fstack-protector-all -Wstrict-overflow -Wl,-z,noexecstack
-Wl,-z,relro -Wl,-z,now
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/home/jeffrey/Desktop/sipwitch-1.3.1':
configure: error: C compiler cannot create executables
See `config.log' for more details

Because LDFLAGS cannot distinguish between executables and shared
objects, I was told to use -fPIC -pic: using -fPIC instead of -fPIE
is always ok [1].

Any ideas how to get automake and friends to build ASLR enabled
executables and shared objects in this manner?

Thanks in advance
Jeff

[1] Request: Add -aslr switch that invokes -fPIE/-pie or -fPIC/-shared
as appropriate, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52885

Re: Dynamic package version numbers with Autoconf and Automake

[Robert Boehne]

On 08/15/12 08:45, Bob Friesenhahn wrote:

On Wed, 15 Aug 2012, Miles Bader wrote:


(3) The final version info is updated (using VCS info and/or autoconf
   version info) at make time using a script, and when it changes,
   only causes a source file (e.g., version.c) to change.

   This means that although some things are rebuilt after a commit
   (version.o, and relinking of any binaries that use it), the amount
   of rebuilding is relatively minor while still yielding accurate
   info.


Likewise, GraphicsMagick configures a version.h as well as a version 
file used for non-autotools builds under Windows.  With the currently 
used mechanism, only the few files depending on version.h need to be 
rebuilt but the whole project relinks.


If the project config.h was to be re-generated (seems to be 
necessary with new AC_INIT), then all of the source modules would need 
to be recompiled and relinked since everything depends on the 
configuration header.


Bpb


I've had a similar complaint when using Autotest.  In my project, the 
test suite depends on an M4 input file that has the project version 
encoded in it.

 cat test_suite/package.m4
# Signature of the current package.
m4_define([AT_PACKAGE_NAME],  [my_server])
m4_define([AT_PACKAGE_TARNAME],  [my_server])
m4_define([AT_PACKAGE_MINOR_VERSION], 4.18)
m4_define([AT_PACKAGE_VERSION],  [4.18.5])
m4_define([AT_PACKAGE_STRING],  [my_server 4.18.5])

Which is created by a makefile rule as suggested in the autoconf 
documentation:


http://www.gnu.org/software/autoconf/manual/autoconf.html#Making-testsuite-Scripts

So when I change the version of the package, I autoreconf, then make 
then autoreconf again.


Scenario #2 -

I have inherited a library versioning scheme that doesn't play nice with 
Libtool  (an absolute requirement)

when the Automake name is not encoded with the version -

  lib_LTLIBRARIES = libmy_server-4.18.la

 So every time I change the version argument to AC_INIT, I have to 
search around my makefiles for anything

that references each library and make the same changes there.

So I would be very interested in a solution to these issues.

Cheers,

Robert

Re: should an empty pkgdata_DATA cause creation of $(pkgdatadir) by make install?

[Robert Boehne]

 On 03/13/12 07:30, Stefano Lattarini wrote:

[CC:ing Ralf, as I'd like to hear his opinion here]

Reference:
  http://lists.gnu.org/archive/html/bug-gnulib/2012-03/msg00078.html

On 03/13/2012 01:14 PM, Stefano Lattarini wrote:

Now that I think about it, I'm not sure whether it was done by design from
the beginning,


And I also missed Ralf's answer here:

  http://comments.gmane.org/gmane.comp.gnu.gsasl.general/52

So we're in a sort of a tie here: some users think that the current Automake
behaviour is a feature (and I lean toward that position), other ones (with
Ralf among them, apparently) believe it's a bug.  Hmmm.  What now?

Regards,
   Stefano


I would agree with the feature camp.  Users should be able to create  
an empty $(pkgdatadir) - suppose that empty directory is populated by 
other methods.  They should also be able to not create $(pkgdatadir) as 
well as a non-empty $(pkgdatadir).


IMHO - whether this was by design or by accident isn't important.  
What's more important is that the behavior is intuitive, and this 
behavior (to me) is intuitive.


Robert Boehne

Re: *simple* example using Autotest

[Robert Boehne]

 On 02/07/12 16:46, Eric Blake wrote:

On 02/07/2012 03:08 PM, Robert Boehne wrote:

  All,

I'd like to start using Autotest in a project (that needs is badly) but
the full-featured GNU M4 example is a bit hard to wrap my head around.
Can anyone suggest another project I could look at as an example, that
has more basic/rudimentary Autotest use?

Automake is probably the wrong list to ask, since autotest is provided
by autoconf, and automake isn't using autotest.  But here are several
projects I know of that use autotest:

autoconf itself
m4
bison
libtool

some of them easier than others to figure out, but that should hopefully
help you get started on seeing how others have used it.


Right you are, this should have gone to the Autoconf list.  I was surprised
to see Libtool on this list, as back when I was actively developing it,
Autotest wasn't available (and hence, not used there).

Thanks Eric!

*simple* example using Autotest

[Robert Boehne]

 All,

I'd like to start using Autotest in a project (that needs is badly) but 
the full-featured GNU M4 example is a bit hard to wrap my head around.
Can anyone suggest another project I could look at as an example, that 
has more basic/rudimentary Autotest use?


Thanks,

Robert

Re: Weird problem with LIBADD

[Robert Boehne]

   Ralf Wildenhues wrote:

* Sylvestre Ledru wrote on Fri, Oct 06, 2006 at 04:24:14PM CEST:
  

Show how you create this library:
  $(top_builddir)/modules/signal_processing/libsignal_processing.la
(i.e., the command line used to create it).  It looks like it depends on
libcore.la (which would be a circular dependency).
  

Pff, Ok, you are right. It was my fault. There are many cyclics deps in
the library of the software that I am building and it can be quite
boring...
I guess it is not very easy for you to detect this kind of things but if
you could, it would be great (the error message is not explicit).


Sounds like a good idea to try this at least.  I added this to Libtool
TODO list: [1]http://wiki.azazil.net/GnuLibtoolProject/RoadMap

Cheers,
Ralf

   The best thing to do with circular dependencies is to untangle them
   so they aren't circular anymore.  There are major problems
   with trying to maintain a set of libraries that have circular dependencies.
   Portability is one issue, another is the fact that you'll get problems
   like the one in your original post.
  I would think that most software engineers
   (as opposed to physicists - *wink*) would liken supporting
   circular lbrary dependencies to designing an automobile that still
   ran even when lage amounts of tar were put in the gas tank.
   It can be done (with great expense), but wouldn't it be better
   to not put the tar in the gas tank in the first place?
   The best way to fix this is to organize your software
   to have separate libraries that have a particular purpose,
   with a pyramid structure.  More low level libraries at the
   bottom, and fewer, higher-level libraries at the top.
   If you can't get the time to do it right, you can cheat by
   putting all the libraries in a circular dependency loop
   into a single library.   Another potential method of cheating
   is to wait until runtime to load them (i.e. use dlopen).
   HTH,
   Robert Boehne

References

   1. http://wiki.azazil.net/GnuLibtoolProject/RoadMap

Re: Automake 1.7.2b uploaded (beta for 1.7.3)

[Robert Boehne]

Alexandre:

The dir file in ${prefix}/info is created by this command:
install-info --info-dir=/net/testme/info /net/testme/info/libtool.info
It makes sense that this file still exists after make uninstall
because unless it is alone in the directory, it should still exist.

The other files were eventually tracked down to libltdl/Makefile.am's
local-install-files rule, checked in as 1.30 May 22, 1999.
ChangeLog entry:
* libltdl/Makefile.am (local-install-files):  New rule to install
libltdl without creating links or mode 777 directories.

The rule itself has a tell-tale FIXME: in it, which I would have found
if this rule was run by make install in the libltdl subdir, but
instead
it is run by install-data-hook in the top-level Makefile.

## This allows us to install libltdl without using ln and without
creating
## a world writeable directory.
## FIXME:  Removed this rule once automake can do this properly by
itself.
local-install-files: $(DISTFILES)
-rm -rf $(DESTDIR)$(datadir)/libtool/libltdl
$(mkinstalldirs) $(DESTDIR)$(datadir)/libtool/libltdl
@for file in $(DISTFILES); do \
  d=$(srcdir); \
  if test -d $$d/$$file; then \
cp -pr $$d/$$file $(DESTDIR)$(datadir)/libtool/libltdl/$$file; \
  else \
test -f $(DESTDIR)$(datadir)/libtool/libltdl/$$file \
|| cp -p $$d/$$file $(DESTDIR)$(datadir)/libtool/libltdl/$$file ||
:; \
  fi; \
done

And from the top-level Makefile.am, this rule to run the above:

# Create and install libltdl
install-data-hook:
cd libltdl  $(MAKE) local-install-files

Because $(DISTFILES) contains ../config.guess ../config.sub
../install-sh
../mkinstalldirs ../ltmain.sh and ../missing, these files are installed
by the local-install-files rule as
 ${datadir}/libtool/libltd/../config.guess
and so on, and these are then not cleaned by this rule from the
top-level Makefile.am:
# Uninstall libltdl
uninstall-local:
-rm -rf $(DESTDIR)$(pkgdatadir)/libltdl

Because they reside in the wrong directory.  The simplest way I can get
around this trouble would be to add the three files that don't get
cleaned by uninstall to the uninstall-local rule, but is there a
cleaner way for Automake to handle all this itself?  I could also use
basename in the local-install-files rule to transform ../foo to foo
but is that portable enough to use?

Probably of more concern to the readers is the conculsion that this
problem wasn't Automake's fault.

Thanks,

Robert

Alexandre Duret-Lutz wrote:
 
  Robert == Robert Boehne [EMAIL PROTECTED] writes:
 
 [...]
 
  Robert these files are installed by make install,
 
 Could you send the output of `make install', so we see exactly
 when these files are installed?
 
  Robert which is run as a dependency of distcheck.  Any ideas
  Robert why this is happening?  I began to look into this
  Robert problem because another maintainer has not been able to
  Robert run make distcheck since he abandoned a much older
  Robert Automake.
 
 Which version worked last?
 
 [...]
 
 --
 Alexandre Duret-Lutz

Re: Automake 1.7.2b uploaded (beta for 1.7.3)

[Robert Boehne]

Alexandre,

Ok, I have Automake 1.7.2b, Autoconf 2.57, Texinfo 4.2 (also tried 4.5)
Make 3.79.1 and bash 2.05a.0(1)-release.  I removed everything
in my libtool directory but the top-level CVS directory, then
did an update to get current cvs.  ./bootstrap  ./configure \
--prefix=/net/testme  make  make install
make uninstall
ls -alR /net/testme/

and I get exactly the same result, the same files left over.
So to answer your question directly, these files are installed
by make install, which is run as a dependency of distcheck.
Any ideas why this is happening?  I began to look into this
problem because another maintainer has not been able to run
make distcheck since he abandoned a much older Automake.
Let me know if I can provide more information.

Thanks,

Robert


Alexandre Duret-Lutz wrote:
 
  Robert == Robert Boehne [EMAIL PROTECTED] writes:
 
  Robert Hello,
  Robert I have a problem with the beta, after bootstrapping a
  Robert fresh checkout of Libtool with Autoconf 2.57 and Automake
  Robert 1.7.2b, I get a make distcheck error.  Apparently the
  Robert distcheck fails because files are left over in the
  Robert insallation directory after make uninstall is run.
 
 I was luckier: CVS Libtool distchecks succesfully here.
 
 I'm using Debian unstable, with Autoconf 2.57, Automake 1.7.2b,
 Libtool 1.4e, Texinfo 4.3a, Make 3.80, Bash 2.05b.0(1)-release.
 
 My install-info is that from Texinfo, not from Debian.
 (Maybe Debian's install-info creates the ${infodir}/dir file?)
 
  Robert Below are the offending files
  Robert ${infodir}/dir
  Robert ${prefix}/share/libtool:
  Robert install-sh  missing  mkinstalldirs
 
 Any idea when these files get installed?
 Are they installed by `make install'?  (i.e., outside distcheck')
 --
 Alexandre Duret-Lutz

Re: Automake 1.7.2b uploaded (beta for 1.7.3)

[Robert Boehne]

Hello,

I have a problem with the beta, after bootstrapping a
fresh checkout of Libtool with Autoconf 2.57 and Automake
1.7.2b, I get a make distcheck error.  Apparently the
distcheck fails because files are left over in the
insallation directory after make uninstall is run.
Below are the offending files
 ${infodir}/dir
 ${prefix}/share/libtool:
install-sh  missing  mkinstalldirs

Is this a bug or misuse?

Robert Boehne


ERROR: files left after uninstall:
./share/libtool/install-sh
./share/libtool/missing
./share/libtool/mkinstalldirs
./info/dir
make[1]: *** [distuninstallcheck] Error 1
make[1]: Leaving directory `/net/libtool/libtool-1.4e/_build'
make: *** [distcheck] Error 2
[rbo@lucifer libtool]$ ls -R /net/libtool/libtool-1.4e/_inst
/net/libtool/libtool-1.4e/_inst:
bin  include  info  lib  share

/net/libtool/libtool-1.4e/_inst/bin:

/net/libtool/libtool-1.4e/_inst/include:

/net/libtool/libtool-1.4e/_inst/info:
dir

/net/libtool/libtool-1.4e/_inst/lib:

/net/libtool/libtool-1.4e/_inst/share:
aclocal  libtool

/net/libtool/libtool-1.4e/_inst/share/aclocal:

/net/libtool/libtool-1.4e/_inst/share/libtool:
install-sh  missing  mkinstalldirs


Alexandre Duret-Lutz wrote:
 
 Hi people!
 
 Here is a snapshot of the 1.7.x branch of Automake.
 
   ftp://alpha.gnu.org/gnu/automake/automake-1.7.2b.tar.gz
   ftp://alpha.gnu.org/gnu/automake/automake-1.7.2b.tar.bz2
   ftp://sources.redhat.com/pub/automake/automake-1.7.2b.tar.gz
   ftp://sources.redhat.com/pub/automake/automake-1.7.2b.tar.bz2
 
 This should be reasonably close to what 1.7.3 will be.
 Please test it and report any problem you have to [EMAIL PROTECTED].
 I hope we can release 1.7.3 by the middle of next week.
 
   There is a known bug with VPATH handling of Texinfo and Lex rules
   which isn't fixed here.  This affects all 1.7.x versions for Texinfo
   rules.  I think older versions will also fails on Lex rules but I
   haven't verified.  This is triggered during VPATH builds with (at
   least) Tru64 make, FreeBSD (current) make, and OpenBSD (3.2) make.
   In short, these make implementations will *not* perform a
   VPATH search for dependencies which appear as targets in Makefiles.
   As far as BSD make is concerned this seems to be a recent change in
   its behavior, as I believe it worked fine in the past.
   Fixing this requires too much changes for the 1.7.x branch.
 
   The following failures in the test suite can denote this bug:
 lex3.test, txinfo3.test, txinfo13.test, txinfo16.test, txinfo18.test
 
   Please report these failures anyway, with your system's version,
   so we know more precisely where this happens.
 
 Here is a list of changes since 1.7.1.  Those that worry me the more
 are the changes to elisp compilation, and the changes to depcomp.  If
 you can test these, by all means please do!
 
 Bugs fixed in 1.7.2b:
 * Fix stamp files numbering (when using multiple AC_CONFIG_HEADERS).
 * Query distutils for `pythondir' and `pythonexecdir', instead of
   using an hardcoded path.  This should allow builds on 64-bit
   distributions that usually use lib64/ instead of lib/.
 * AM_PATH_PYTHON will also search for python2.3.
 * elisp files are now built all at once instead of one by one. Besides
   incurring a speed-up, this is required to support interdependent elisp files.
 * Support for DJGPP:
   - `make distcheck' will now work in `_inst/' and `_build' instead
 of `=inst/' and `=build/'
   - use `_dirstamp' when the file-system doesn't support `.dirstamp'
   - more changes that affect only the Automake package (not its output)
 * Fix some incompatibilities with upcoming perl-5.10.
 * Properly quote AC_PACKAGE_TARNAME and AC_PACKAGE_VERSION when defining
   PACKAGE and VERSION.
 * depcomp fixes:
   - dashmstdout and dashXmstdout modes: don't use `-o /dev/null', this
 is troublesome with gcc and Solaris compilers. (PR/385)
   - makedepend mode: work with Libtool. (PR/385 too)
   - support for ICC.
 * better support for unusual gettext setups, such as multiple po/ directories
   (PR/381):
   - Flag missing po/ and intl/ directories as warnings, not errors.
   - Disable these warnings if po/ does not exist.
 * Noteworthy manual updates:
   - New FAQ chapter.
   - Document how AC_CONFIG_AUX_DIR interacts with missing files.
 (Debian Bug #39542)
   - Document `AM_YFLAGS = -d'.  (PR/382)
 
 --
 Alexandre Duret-Lutz

DEPDIR not set by current CVS Automake

[Robert Boehne]

Hello all,

I'm having problems with my Libtool/Automake project when
using dependency tracking.  It seem that the variable
DEPDIR isn't set anywhere in any of the Makefiles.
This may be because the top level Makefile doesn't have
any targets that aren't in subdirs.
  I think this is a bug as it worked in previous versions
of Automake.

Thanks,

Robert

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

Re: PATCH: Fix dependency tracking (revised)

[Robert Boehne]

Tom Tromey wrote:
 
  Robert == Robert Boehne [EMAIL PROTECTED] writes:
 
 Robert 2001-04-25  Robert Boehne [EMAIL PROTECTED]
 Robert * configure.in: Add _am_dep_true='@AMDEP_TRUE@' and AC_SUBST it.
 Robert * automake.in: (handle_dependencies) Replace @AMDEP_TRUE@ in
 Robert $output_rules with @_am_dep_true@ so that @AMDEP_TRUE@ isn't
 Robert substituted away when automake is created by configure.
 Robert * depend2.am: Add @AMDEP_TRUE@ to the beginning of lines for
 Robert dependency tracking in the rules for object files so that
 Robert disabling dependency tracking with 'configure' will work.
 Robert * configure: Regenerate.
 
 Thanks for this patch.
 I fixed in a different way before I saw this patch.
 Can you try the current automake?
 Your changes to depend2.am leave me thinking that maybe my fix isn't
 complete.  (Or maybe your fix is redundant?)
 
 Tom

Tom:

The latest CVS Automake works fine for --enable-dependency-tracking,
but when --disable-dependency-tracking is specified it's still choking.
The problem is that the lines required for depcomp when dependency
tracking is used are not valid.  When the package is configured,
the Automake conditionals aren't evaluated, they are evaluated
when Automake is run on the package.  Here's a snippet:

#include $(DEPDIR)/Units_UnitsDictionary.Plo
#include $(DEPDIR)/Units_UnitsLexicon.Plo
#include $(DEPDIR)/Units_UnitsSequence_0.Plo
#include $(DEPDIR)/Units_UnitsSystem.Plo
#include $(DEPDIR)/Units_UtsSequence_0.Plo

distclean-depend:
-rm -rf $(DEPDIR)

CXXDEPMODE = depmode=none

.cxx.o:
source='$' object='$@' libtool=no 
depfile='$(DEPDIR)/$*.Po' tmpdepfile='$(DEPDIR)/$*.TPo' 
$(CXXDEPMODE) $(depcomp) 
$(CXXCOMPILE) -c -o $@ `test -f $ || echo '$(srcdir)/'`$

So the file depend2.am still needs to have @AMDEP_TRUE@ before
the tab on the first three lines of the rule.  Alternatively
@AMDEPBACKSLASH@ could be set to \, but that would lengthen
compile times by running 'depcomp mode=none' on every source file.

I like the trick you used to get @AMDEP_TRUE@ to stay in
automake after configuring, I'll have to remember that.  :)

Thanks,

Robert

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

Re: PATCH: Fix dependency tracking (revised)

[Robert Boehne]

Tom Tromey wrote:
 
  Robert == Robert Boehne [EMAIL PROTECTED] writes:
 
 Robert 2001-04-25  Robert Boehne [EMAIL PROTECTED]
 Robert * configure.in: Add _am_dep_true='@AMDEP_TRUE@' and AC_SUBST it.
 Robert * automake.in: (handle_dependencies) Replace @AMDEP_TRUE@ in
 Robert $output_rules with @_am_dep_true@ so that @AMDEP_TRUE@ isn't
 Robert substituted away when automake is created by configure.
 Robert * depend2.am: Add @AMDEP_TRUE@ to the beginning of lines for
 Robert dependency tracking in the rules for object files so that
 Robert disabling dependency tracking with 'configure' will work.
 Robert * configure: Regenerate.
 
 Thanks for this patch.
 I fixed in a different way before I saw this patch.
 Can you try the current automake?
 Your changes to depend2.am leave me thinking that maybe my fix isn't
 complete.  (Or maybe your fix is redundant?)
 
 Tom

Here's the patch for depend2.am that I intended to send.  ;)

Robert


-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

Index: depend2.am
===
RCS file: /cvs/automake/automake/depend2.am,v
retrieving revision 1.36
diff -u -r1.36 depend2.am
--- depend2.am  2001/04/27 12:55:48 1.36
+++ depend2.am  2001/05/07 13:22:27
@@ -31,9 +31,9 @@
 ?GENERIC?.%EXT%.o:
 ?!GENERIC?%OBJ%: %SOURCE%
 if %AMDEP%
-   source='%SOURCE%' object='%OBJ%' libtool=no @AMDEPBACKSLASH@
-   depfile='$(DEPDIR)/%BASE%.Po' tmpdepfile='$(DEPDIR)/%BASE%.TPo' 
@AMDEPBACKSLASH@
-   $(%FPFX%DEPMODE) $(depcomp) @AMDEPBACKSLASH@
+@AMDEP_TRUE@   source='%SOURCE%' object='%OBJ%' libtool=no @AMDEPBACKSLASH@
+@AMDEP_TRUE@   depfile='$(DEPDIR)/%BASE%.Po' tmpdepfile='$(DEPDIR)/%BASE%.TPo' 
+@AMDEPBACKSLASH@
+@AMDEP_TRUE@   $(%FPFX%DEPMODE) $(depcomp) @AMDEPBACKSLASH@
 endif %AMDEP%
%COMPILE% -c -o %OBJ% `test -f %SOURCE% || echo '$(srcdir)/'`%SOURCE%
 
@@ -41,9 +41,9 @@
 ?GENERIC?.%EXT%.lo:
 ?!GENERIC?%LTOBJ%: %SOURCE%
 if  %AMDEP%
-   source='%SOURCE%' object='%LTOBJ%' libtool=yes @AMDEPBACKSLASH@
-   depfile='$(DEPDIR)/%BASE%.Plo' tmpdepfile='$(DEPDIR)/%BASE%.TPlo' 
@AMDEPBACKSLASH@
-   $(%FPFX%DEPMODE) $(depcomp) @AMDEPBACKSLASH@
+@AMDEP_TRUE@   source='%SOURCE%' object='%LTOBJ%' libtool=yes @AMDEPBACKSLASH@
+@AMDEP_TRUE@   depfile='$(DEPDIR)/%BASE%.Plo' tmpdepfile='$(DEPDIR)/%BASE%.TPlo' 
+@AMDEPBACKSLASH@
+@AMDEP_TRUE@   $(%FPFX%DEPMODE) $(depcomp) @AMDEPBACKSLASH@
 endif  %AMDEP%
%LTCOMPILE% -c -o %LTOBJ% `test -f %SOURCE% || echo '$(srcdir)/'`%SOURCE%
 endif %?LIBTOOL%
@@ -51,8 +51,8 @@
 ?GENERIC?.%EXT%.obj:
 ?!GENERIC?%OBJOBJ%: %SOURCE%
 if %AMDEP%
-   source='%SOURCE%' object='%OBJOBJ%' libtool=no @AMDEPBACKSLASH@
-   depfile='$(DEPDIR)/%BASE%.Po' tmpdepfile='$(DEPDIR)/%BASE%.TPo' 
@AMDEPBACKSLASH@
-   $(%FPFX%DEPMODE) $(depcomp) @AMDEPBACKSLASH@
+@AMDEP_TRUE@   source='%SOURCE%' object='%OBJOBJ%' libtool=no @AMDEPBACKSLASH@
+@AMDEP_TRUE@   depfile='$(DEPDIR)/%BASE%.Po' tmpdepfile='$(DEPDIR)/%BASE%.TPo' 
+@AMDEPBACKSLASH@
+@AMDEP_TRUE@   $(%FPFX%DEPMODE) $(depcomp) @AMDEPBACKSLASH@
 endif %AMDEP%
%COMPILE% -c -o %OBJOBJ% `cygpath -w %SOURCE%`

PATCH: Fix dependency tracking (revised)

[Robert Boehne]

Problem:
  Makefile.in's created with --include-deps do not allow configure
to turn off dependency tracking.  If --disable-dependency-tracking
is specified to configure, the rules for object files are invalid,
causing make to exit without building anything.  Also, if a compiler
that does not support dependencies is used, the same problem occurrs
when --enable-dependency-tracking is specified to configure.

Solution:
  The reasons for this are that @AMDEP_TRUE@ in the handle_dependencies
function (subroutine?) is AC_SUBST'd to  when automake is created
from automake.in.  The object file rules in depend2.am must also be
adjusted to remove the 'depcomp' lines completely if dependency
tracking is not desired or available.  If not, these rules will
attempt to execute these lines as separate commands because 
@AMDEPBACKSLASH@ is substituted with  when dependency tracking
is off.


ChangeLog entry:

2001-04-25  Robert Boehne [EMAIL PROTECTED]

* configure.in: Add _am_dep_true='@AMDEP_TRUE@' and AC_SUBST it.
* automake.in: (handle_dependencies) Replace @AMDEP_TRUE@ in
$output_rules with @_am_dep_true@ so that @AMDEP_TRUE@ isn't
substituted away when automake is created by configure.
* depend2.am: Add @AMDEP_TRUE@ to the beginning of lines for
dependency tracking in the rules for object files so that
disabling dependency tracking with 'configure' will work.
* configure: Regenerate.


-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

Index: automake.in
===
RCS file: /cvs/automake/automake/automake.in,v
retrieving revision 1.1046
diff -u -r1.1046 automake.in
--- automake.in 2001/04/24 18:00:14 1.1046
+++ automake.in 2001/04/25 20:18:50
@@ -3229,7 +3229,7 @@
$output_rules .= \n;
foreach my $iter (@deplist)
{
-   $output_rules .= ('@AMDEP_TRUE@@_am_include@ @_am_quote@'
+   $output_rules .= ('@_am_dep_true@ @_am_include@ @_am_quote@'
  . $iter . '@_am_quote@' . \n);
}
 
Index: configure
===
RCS file: /cvs/automake/automake/configure,v
retrieving revision 1.81
diff -u -r1.81 configure
--- configure   2001/04/24 09:44:16 1.81
+++ configure   2001/04/25 20:18:50
@@ -676,7 +676,7 @@
   echo configure: warning: ${am_backtick}missing' script is too old or missing 12
 fi
 
-for ac_prog in mawk gawk nawk awk
+for ac_prog in gawk mawk nawk awk
 do
 # Extract the first word of $ac_prog, so it can be a program name with args.
 set dummy $ac_prog; ac_word=$2
@@ -904,6 +904,7 @@
 $PERL -e 'require 5.005;' || {
{ echo configure: error: perl 5.005 or better is required 12; exit 1; }
 }
+_am_dep_true='@AMDEP_TRUE@'
 
 trap '' 1 2 15
 cat  confcache \EOF
@@ -1072,6 +1073,7 @@
 s%@AMDEPBACKSLASH@%$AMDEPBACKSLASH%g
 s%@DEPDIR@%$DEPDIR%g
 s%@PERL@%$PERL%g
+s%@_am_dep_true@%$_am_dep_true%g
 
 CEOF
 EOF
Index: configure.in
===
RCS file: /cvs/automake/automake/configure.in,v
retrieving revision 1.77
diff -u -r1.77 configure.in
--- configure.in2001/02/16 05:56:09 1.77
+++ configure.in2001/04/25 20:18:50
@@ -13,6 +13,7 @@
 $PERL -e 'require 5.005;' || {
AC_MSG_ERROR([perl 5.005 or better is required])
 }
-
+_am_dep_true='@AMDEP_TRUE@'
+AC_SUBST(_am_dep_true)
 AC_OUTPUT([Makefile automake aclocal m4/Makefile tests/Makefile],
 [chmod +x automake aclocal])
Index: depend2.am
===
RCS file: /cvs/automake/automake/depend2.am,v
retrieving revision 1.35
diff -u -r1.35 depend2.am
--- depend2.am  2001/04/11 17:29:06 1.35
+++ depend2.am  2001/04/25 20:18:50
@@ -31,9 +31,9 @@
 ?GENERIC?%EXT%.o:
 ?!GENERIC?%OBJ%: %SOURCE%
 if %AMDEP%
-   source='%SOURCE%' object='%OBJ%' libtool=no @AMDEPBACKSLASH@
-   depfile='$(DEPDIR)/%BASE%.Po' tmpdepfile='$(DEPDIR)/%BASE%.TPo' 
@AMDEPBACKSLASH@
-   $(%FPFX%DEPMODE) $(depcomp) @AMDEPBACKSLASH@
+@AMDEP_TRUE@   source='%SOURCE%' object='%OBJ%' libtool=no @AMDEPBACKSLASH@
+@AMDEP_TRUE@   depfile='$(DEPDIR)/%BASE%.Po' tmpdepfile='$(DEPDIR)/%BASE%.TPo' 
+@AMDEPBACKSLASH@
+@AMDEP_TRUE@   $(%FPFX%DEPMODE) $(depcomp) @AMDEPBACKSLASH@
 endif %AMDEP%
%COMPILE% -c -o %OBJ% `test -f %SOURCE% || echo '$(srcdir)/'`%SOURCE%
 
@@ -41,9 +41,9 @@
 ?GENERIC?%EXT%.lo:
 ?!GENERIC?%LTOBJ%: %SOURCE%
 if  %AMDEP%
-   source='%SOURCE%' object='%LTOBJ%' libtool=yes @AMDEPBACKSLASH@
-   depfile='$(DEPDIR)/%BASE%.Plo' tmpdepfile='$(DEPDIR)/%BASE%.TPlo' 
@AMDEPBACKSLASH@
-   $(%FPFX%DEPMODE) $(depcomp) @AMDEPBACKSLASH@
+@AMDEP_TRUE@   source='%SOURCE%' object='%LTOBJ%' libtool=yes @AMDEPBACKSLASH@
+@AMDEP_TRUE@   depfile='$(DEPDIR)/%BASE%.Plo

Re: Bug when specifying --disable-dependency-tracking (AM_DEP_TRACK)

[Robert Boehne]

Alexandre Oliva wrote:
 
 On Apr 18, 2001, Robert Boehne [EMAIL PROTECTED] wrote:
 
  .c.o:
source='$' object='$@' libtool=no @AMDEPBACKSLASH@
depfile='$(DEPDIR)/$*.Po' tmpdepfile='$(DEPDIR)/$*.TPo'
  @AMDEPBACKSLASH@
$(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
$(COMPILE) -c -o $@ `test -f $ || echo '$(srcdir)/'`$
 
 AFAICT, this was not generated by the automake that corresponds to the
 new m4/depend.m4.  The new version should have `#'s in the beginning
 of the lines containing AMDEPBACKSLASH.  This should have been a
 result of the new if/endif AMDEP rules in depend2.am.
 
 However, I see the change that introduced AMDEP as a conditional has
 removed the test for the existence of the depcomp script.  Hmm...
 Perhaps this is not necessary, since this very script is used to
 choose a dependency tracking mechanism, so we'd end up with `no' if it
 doesn't exist.  Yeah, that makes sense...
 

Alexandre:
  I double checked that my aclocal has included the same version
of m4/depend.m4 as the current CVS repository.  It does.
It looks to me like @AMDEPBACKSLASH@ is not conditional, if Automake
is run with --include-deps, then it needs the backslash, if not,
these lines are commented out.  When --include-deps was specified
to Automake, but --disable-dependency-tracking was specified to
configure, then the lines aren't commented out, and the backslash
is still needed because the rules exist but with depmode=none
specified on the command line.  

automake --include-deps gives:

.cxx.lo:
source='$' object='$@' libtool=yes @AMDEPBACKSLASH@
depfile='$(DEPDIR)/$*.Plo' tmpdepfile='$(DEPDIR)/$*.TPlo'
@AMDEPBACKSLASH@
$(CXXDEPMODE) $(depcomp) @AMDEPBACKSLASH@
$(LTCXXCOMPILE) -c -o $@ `test -f $ || echo '$(srcdir)/'`$

automake --ignore-deps gives:

.cxx.lo:
$(LTCXXCOMPILE) -c -o $@  $

Everything is OK with --ignore-deps, this only is a concern
when dependency tracking is supported in the Makefile.in, but
the user or compiler doesn't want or support it.

The problem seems to me that when dependency tracking was
changed to use automake conditionals, the following code
from depend2.am (current CVS) was not changed properly.
Unconditionally setting AMDEPBACKSLASH='\' will work
around the problem, but these lines need to get removed
at *configure* time when --disable-dependency-tracking is
specified.  This cannot be done with an Automake conditional
because it is done at configure time.

if %?LIBTOOL%
?GENERIC?%EXT%.lo:
?!GENERIC?%LTOBJ%: %SOURCE%
if  %AMDEP%
source='%SOURCE%' object='%LTOBJ%' libtool=yes @AMDEPBACKSLASH@
depfile='$(DEPDIR)/%BASE%.Plo' tmpdepfile='$(DEPDIR)/%BASE%.TPlo'
@AMDEPBACKSLASH@
$(%FPFX%DEPMODE) $(depcomp) @AMDEPBACKSLASH@
endif  %AMDEP%
%LTCOMPILE% -c -o %LTOBJ% `test -f %SOURCE% || echo
'$(srcdir)/'`%SOURCE%
endif %?LIBTOOL%

Trust me, this is a problem with Automake, I've doublechecked.

Robert

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

Re: Bug when specifying --disable-dependency-tracking (AM_DEP_TRACK)

[Robert Boehne]

CVS version of aclocal.m4 doesn't match CVS m4/depend.m4,
could that cause a problem?

Robert Boehne wrote:
 
 Hello,
 
 There is a bit of a problem in CVS Automake (Today's) when
 --disable-dependency-tracking is specified to configure.
 If dependency tracking rules have been added to Makefile.in,
 the rules created have @AMDEPBACKSLASH@ at the end of the
 lines that tell depcomp the required variables source,
 depfile, and depmode.  'depcomp' fails (hence so does the build
 if these variables are not specified when it is invoked.
 Currently, when --disable-dependency-tracking is specified,
 depmode is set to 'none', but then AM_DEP_TRACK removes
 the line continuation backslashes from the make rule.
 A quick fix is to comment out the test around AMDEPBACKSLASH
 #if test x$enable_dependency_tracking != xno; then
   am_depcomp=$ac_aux_dir/depcomp
   AMDEPBACKSLASH='\'
 #fi
 This unconditionally adds the backslashes so depcomp doesn't fail.
   I'm not sure if the maintainers would prefer a different
 solution, so no patch is pending unless you ask.
 
 Thanks!
 
 Robert
 
 from Makefile.in:
 
 .c.o:
 source='$' object='$@' libtool=no @AMDEPBACKSLASH@
 depfile='$(DEPDIR)/$*.Po' tmpdepfile='$(DEPDIR)/$*.TPo'
 @AMDEPBACKSLASH@
 $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
 $(COMPILE) -c -o $@ `test -f $ || echo '$(srcdir)/'`$
 
 from CVS m4/depend.m4:
 
 # AM_DEP_TRACK
 # 
 AC_DEFUN([AM_DEP_TRACK],
 [AC_ARG_ENABLE(dependency-tracking,
 [  --disable-dependency-tracking Speeds up one-time builds
   --enable-dependency-tracking  Do not reject slow dependency
 extractors])
 if test x$enable_dependency_tracking != xno; then
   am_depcomp=$ac_aux_dir/depcomp
   AMDEPBACKSLASH='\'
 fi
 AM_CONDITIONAL([AMDEP], [test x$enable_dependency_tracking != xno])
 pushdef([subst], defn([AC_SUBST]))
 subst(AMDEPBACKSLASH)
 popdef([subst])
 ])
 
 --
 Robert Boehne Software Engineer
 Ricardo Software   Chicago Technical Center
 TEL: (630)789-0003 x. 238
 FAX: (630)789-0127
 email:  [EMAIL PROTECTED]

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

Re: Bug when specifying --disable-dependency-tracking (AM_DEP_TRACK)

[Robert Boehne]

OK, here's a bit more info:

In automake.in this code appears:

foreach my $iter (@deplist)
{
$output_rules .= ('@AMDEP_TRUE@@_am_include@ @_am_quote@'
  . $iter . '@_am_quote@' . \n);
}

Which, if it added @AMDEP_TRUE@ to the Makefile.in's would work,
but when I execute 'make' the automake that is produced has
this code instead of the above:

foreach my $iter (@deplist)
{
$output_rules .= (' @_am_include@ @_am_quote@'
  . $iter . '@_am_quote@' . \n);
}

Where did @AMDEP_TRUE@ go?

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

PATCH: Fix dependency tracking

[Robert Boehne]

Here is a patch that fixes the problems I've been winging about.
Part of the problem appears to be that @AMDEP_TRUE@ is
AC_SUBST'd when automake is generated from automake.in,
so I add a dummy variable and set it to '@AMDEP_TRUE@'
and subst that into automake.in. 

Thanks,

Robert

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

? fixDependencies.patch
Index: Makefile.in
===
RCS file: /cvs/automake/automake/Makefile.in,v
retrieving revision 1.311
diff -u -r1.311 Makefile.in
--- Makefile.in 2001/04/10 12:41:04 1.311
+++ Makefile.in 2001/04/23 22:22:49
@@ -59,7 +59,6 @@
 NORMAL_UNINSTALL = :
 PRE_UNINSTALL = :
 POST_UNINSTALL = :
-AMDEP = @AMDEP@
 AMTAR = @AMTAR@
 AWK = @AWK@
 DEPDIR = @DEPDIR@
@@ -70,7 +69,9 @@
 PERL = @PERL@
 STRIP = @STRIP@
 VERSION = @VERSION@
+_am_dep_true = @_am_dep_true@
 _am_include = @_am_include@
+_am_quote = @_am_quote@
 install_sh = @install_sh@
 
 AUTOMAKE_OPTIONS = gnits 1.4
Index: aclocal.m4
===
RCS file: /cvs/automake/automake/aclocal.m4,v
retrieving revision 1.54
diff -u -r1.54 aclocal.m4
--- aclocal.m4  2001/03/23 16:23:52 1.54
+++ aclocal.m4  2001/04/23 22:22:49
@@ -177,7 +177,7 @@
 [test x${MISSING+set} = xset ||
   MISSING=\${SHELL} `CDPATH=:; cd $ac_aux_dir  pwd`/missing
 # Use eval to expand $SHELL
-if eval $MISSING --run :; then
+if eval $MISSING --run true; then
   am_missing_run=$MISSING --run 
 else
   am_missing_run=
@@ -375,22 +375,11 @@
 [AC_ARG_ENABLE(dependency-tracking,
 [  --disable-dependency-tracking Speeds up one-time builds
   --enable-dependency-tracking  Do not reject slow dependency extractors])
-if test x$enable_dependency_tracking = xno; then
-  AMDEP=#
-else
+if test x$enable_dependency_tracking != xno; then
   am_depcomp=$ac_aux_dir/depcomp
-  if test ! -f $am_depcomp; then
-AMDEP=#
-  else
-AMDEP=
-  fi
-fi
-AC_SUBST(AMDEP)
-if test -z $AMDEP; then
   AMDEPBACKSLASH='\'
-else
-  AMDEPBACKSLASH=
 fi
+AM_CONDITIONAL([AMDEP], [test x$enable_dependency_tracking != xno])
 pushdef([subst], defn([AC_SUBST]))
 subst(AMDEPBACKSLASH)
 popdef([subst])
@@ -452,7 +441,6 @@
 # Check to see how make treats includes.
 AC_DEFUN([AM_MAKE_INCLUDE],
 [am_make=${MAKE-make}
-# BSD make uses .include
 cat  confinc  'END'
 doit:
@echo done
@@ -460,15 +448,54 @@
 # If we don't find an include directive, just comment out the code.
 AC_MSG_CHECKING([for style of include used by $am_make])
 _am_include='#'
-for am_inc in include .include; do
-   echo $am_inc confinc  confmf
-   if test `$am_make -f confmf 2 /dev/null` = done; then
-  _am_include=$am_inc
-  break
+_am_quote=
+_am_result=none
+# First try GNU make style include.
+echo include confinc  confmf
+if test `$am_make -s -f confmf 2 /dev/null` = done; then
+   _am_include=include
+   _am_quote=
+   _am_result=GNU
+fi
+# Now try BSD make style include.
+if test $_am_include = #; then
+   echo '.include confinc'  confmf
+   if test `$am_make -s -f confmf 2 /dev/null` = done; then
+  _am_include=.include
+  _am_quote=''
+  _am_result=BSD
fi
-done
+fi
 AC_SUBST(_am_include)
-AC_MSG_RESULT($_am_include)
+AC_SUBST(_am_quote)
+AC_MSG_RESULT($_am_result)
 rm -f confinc confmf
 ])
+
+# serial 3
+
+# AM_CONDITIONAL(NAME, SHELL-CONDITION)
+# -
+# Define a conditional.
+#
+# FIXME: Once using 2.50, use this:
+# m4_match([$1], [^TRUE\|FALSE$], [AC_FATAL([$0: invalid condition: $1])])dnl
+AC_DEFUN([AM_CONDITIONAL],
+[ifelse([$1], [TRUE],
+[errprint(__file__:__line__: [$0: invalid condition: $1
+])dnl
+m4exit(1)])dnl
+ifelse([$1], [FALSE],
+   [errprint(__file__:__line__: [$0: invalid condition: $1
+])dnl
+m4exit(1)])dnl
+AC_SUBST([$1_TRUE])
+AC_SUBST([$1_FALSE])
+if $2; then
+  $1_TRUE=
+  $1_FALSE='#'
+else
+  $1_TRUE='#'
+  $1_FALSE=
+fi])
 
Index: automake.in
===
RCS file: /cvs/automake/automake/automake.in,v
retrieving revision 1.1045
diff -u -r1.1045 automake.in
--- automake.in 2001/04/23 17:10:22 1.1045
+++ automake.in 2001/04/23 22:22:50
@@ -3222,7 +3222,7 @@
$output_rules .= \n;
foreach my $iter (@deplist)
{
-   $output_rules .= ('@AMDEP_TRUE@@_am_include@ @_am_quote@'
+   $output_rules .= ('@_am_dep_true@ @_am_include@ @_am_quote@'
  . $iter . '@_am_quote@' . \n);
}
 
Index: configure
===
RCS file: /cvs/automake/automake/configure,v
retrieving revision 1.80
diff -u -r1.80 configure
--- configure   2001/03/23 16:23:52 1.80
+++ configure   2001/04/23 22:22:50
@@ -1,29 +1,116 @@
 #! /bin/sh
-
 # Guess values for system-dependent variables and create

Re: @_am_quote@ not replaced by 'configure'

[Robert Boehne]

Robert Boehne wrote:
 
 Hello!
 
 Current CVS sources of Automake leave @_am_quote@
 un-substituted in Makefile's causing make to fail
 if dependencies are requested.
   This is a recent problem, it's existed in CVS for
 only a few days (don't know exactly though).  I did have
 a version of Automake working with dependencies properly
 after Automake conditionals were used, so this was broken
 after that.
 

It seems that I somehow had mixed versions of m4 macro
files as this problem, and another one I posted about
$host not getting set, have disappeared.

   On a related note, I wonder if it would be reasonable
 to add a test case to Automake similar to the style that
 Libtool uses.  A test that actually compiles code and
 attempted to use dependencies, invoke libtool, etc. would
 help find these problems before they get checked in.
 The test could simply be skipped if there is no C/C++/F77/?
 compiler found.  I would be more than happy to contribute
 the test as well.  Any thoughts?

I'd still like to build a realistic test case for Automake,
but before I go to the trouble to do that I'd like to hear
some comments.  The way I look at this is that a real-world
test case will help catch more bugs before they make it into
the cvs repository, but I also understand that keeping
the testsuite short and simple is a concern too.
So where do the maintainers draw this line?

Robert

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

Bug when specifying --disable-dependency-tracking (AM_DEP_TRACK)

[Robert Boehne]

Hello,

There is a bit of a problem in CVS Automake (Today's) when
--disable-dependency-tracking is specified to configure.
If dependency tracking rules have been added to Makefile.in,
the rules created have @AMDEPBACKSLASH@ at the end of the
lines that tell depcomp the required variables source,
depfile, and depmode.  'depcomp' fails (hence so does the build
if these variables are not specified when it is invoked.
Currently, when --disable-dependency-tracking is specified,
depmode is set to 'none', but then AM_DEP_TRACK removes
the line continuation backslashes from the make rule.
A quick fix is to comment out the test around AMDEPBACKSLASH
#if test "x$enable_dependency_tracking" != xno; then
  am_depcomp="$ac_aux_dir/depcomp"
  AMDEPBACKSLASH='\'
#fi
This unconditionally adds the backslashes so depcomp doesn't fail.
  I'm not sure if the maintainers would prefer a different
solution, so no patch is pending unless you ask.

Thanks!

Robert

from Makefile.in:

.c.o:
source='$' object='$@' libtool=no @AMDEPBACKSLASH@
depfile='$(DEPDIR)/$*.Po' tmpdepfile='$(DEPDIR)/$*.TPo'
@AMDEPBACKSLASH@
$(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
$(COMPILE) -c -o $@ `test -f $ || echo '$(srcdir)/'`$

from CVS m4/depend.m4:

# AM_DEP_TRACK
# 
AC_DEFUN([AM_DEP_TRACK],
[AC_ARG_ENABLE(dependency-tracking,
[  --disable-dependency-tracking Speeds up one-time builds
  --enable-dependency-tracking  Do not reject slow dependency
extractors])
if test "x$enable_dependency_tracking" != xno; then
  am_depcomp="$ac_aux_dir/depcomp"
  AMDEPBACKSLASH='\'
fi
AM_CONDITIONAL([AMDEP], [test "x$enable_dependency_tracking" != xno])
pushdef([subst], defn([AC_SUBST]))
subst(AMDEPBACKSLASH)
popdef([subst])
])


-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

@_am_quote@ not replaced by 'configure'

[Robert Boehne]

Hello!

Current CVS sources of Automake leave @_am_quote@
un-substituted in Makefile's causing make to fail
if dependencies are requested.
  This is a recent problem, it's existed in CVS for
only a few days (don't know exactly though).  I did have
a version of Automake working with dependencies properly
after Automake conditionals were used, so this was broken
after that.

  On a related note, I wonder if it would be reasonable
to add a test case to Automake similar to the style that
Libtool uses.  A test that actually compiles code and
attempted to use dependencies, invoke libtool, etc. would
help find these problems before they get checked in.
The test could simply be skipped if there is no C/C++/F77/?
compiler found.  I would be more than happy to contribute
the test as well.  Any thoughts?

Robert

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

depcomp not found if in aux_dir

[Robert Boehne]

Hello:

I'm testing the CVS MLB Libtool with current CVS Automake and Autoconf.
I've found that dependency tracking doesn't work because the depcomp
script is copied into the auxiliary directory specified with
AC_CONFIG_AUX_DIR('directory') as it should, but when the generated
configure script is run for that project, the depcomp script is only
found if it is $(top_srcdir)/depcomp.
I don't know the first thing about perl or I would have sent in a patch,
sorry!
Here is sample output from 'configure':

checking how to run the C++ preprocessor... g++ -E
checking dependency style of g++... cp: /icarus/OCC/OCC/depcomp: No such
file or directory
/icarus/OCC/OCC/configure: ./depcomp: No such file or directory
none

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

depcomp w/ libtool leaves %% in Makefile.in

[Robert Boehne]

Here is a snippet of one of my Makefile.in's in a subdirectory
of a project using CVS MLB Libtool and dependencies.
This was generated with CVS Automake (as of today) with
--include-deps on the command line.
The problem is that the "if %%" line isn't translated
into anything by configure.  I don't understand how this is
supposed to work but I'm sure Akim knows.

Thanks,

Robert


.c.o:
source='$' object='$@' libtool=no @AMDEPBACKSLASH@
depfile='$(DEPDIR)/$*.Po' tmpdepfile='$(DEPDIR)/$*.TPo'
@AMDEPBACKSLASH@
$(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
$(COMPILE) -c -o $@ `test -f $ || echo '$(srcdir)/'`$

if %%
.c.lo:
source='$' object='$@' libtool=yes @AMDEPBACKSLASH@
depfile='$(DEPDIR)/$*.Plo' tmpdepfile='$(DEPDIR)/$*.TPlo'
@AMDEPBACKSLASH@
$(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
$(LTCOMPILE) -c -o $@ `test -f $ || echo '$(srcdir)/'`$
endif %%

.
-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

Re: depcomp w/ libtool leaves %% in Makefile.in

[Robert Boehne]

Akim Demaille wrote:
 
 Please, edit depend2.am and replace
 
 if %?LIBTOOL?%
 
 endif %?LIBTOOL?%
 
 with
 
 if %?LIBTOOL%
 
 endif %?LIBTOOL%
 
 (no ? at the end).  It should make it, right?

That fixed it! I've attached a patch.

Thanks Akim!

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

ChangeLog entry:

2001-04-11  Robert Boehne  [EMAIL PROTECTED]

* depend2.am: Changed %?LIBTOOL?% to %?LIBTOOL%
in libtool object file rule.



Index: depend2.am
===
RCS file: /cvs/automake/automake/depend2.am,v
retrieving revision 1.34
diff -u -r1.34 depend2.am
--- depend2.am  2001/04/09 14:50:47 1.34
+++ depend2.am  2001/04/11 17:32:56
@@ -37,7 +37,7 @@
 endif %AMDEP%
%COMPILE% -c -o %OBJ% `test -f %SOURCE% || echo '$(srcdir)/'`%SOURCE%
 
-if %?LIBTOOL?%
+if %?LIBTOOL%
 ?GENERIC?%EXT%.lo:
 ?!GENERIC?%LTOBJ%: %SOURCE%
 if  %AMDEP%
@@ -46,7 +46,7 @@
$(%FPFX%DEPMODE) $(depcomp) @AMDEPBACKSLASH@
 endif  %AMDEP%
%LTCOMPILE% -c -o %LTOBJ% `test -f %SOURCE% || echo '$(srcdir)/'`%SOURCE%
-endif %?LIBTOOL?%
+endif %?LIBTOOL%
 
 ?GENERIC?%EXT%.obj:
 ?!GENERIC?%OBJOBJ%: %SOURCE%

Re: depcomp w/ libtool leaves %% in Makefile.in

[Robert Boehne]

Ignore this, my email server is just very slow.

Robert

Robert Boehne wrote:
 
 Akim Demaille wrote:
 
  Please, edit depend2.am and replace
 
  if %?LIBTOOL?%
 
  endif %?LIBTOOL?%
 
  with
 
  if %?LIBTOOL%
 
  endif %?LIBTOOL%
 
  (no ? at the end).  It should make it, right?
 
 That fixed it! I've attached a patch.
 
 Thanks Akim!
 
 --
 Robert Boehne Software Engineer
 Ricardo Software   Chicago Technical Center
 TEL: (630)789-0003 x. 238
 FAX: (630)789-0127
 email:  [EMAIL PROTECTED]
 
   
 ChangeLog entry:
 
 2001-04-11  Robert Boehne  [EMAIL PROTECTED]
 
 * depend2.am: Changed %?LIBTOOL?% to %?LIBTOOL%
 in libtool object file rule.
 
 Index: depend2.am
 ===
 RCS file: /cvs/automake/automake/depend2.am,v
 retrieving revision 1.34
 diff -u -r1.34 depend2.am
 --- depend2.am  2001/04/09 14:50:47 1.34
 +++ depend2.am  2001/04/11 17:32:56
 @@ -37,7 +37,7 @@
  endif %AMDEP%
 %COMPILE% -c -o %OBJ% `test -f %SOURCE% || echo '$(srcdir)/'`%SOURCE%
 
 -if %?LIBTOOL?%
 +if %?LIBTOOL%
  ?GENERIC?%EXT%.lo:
  ?!GENERIC?%LTOBJ%: %SOURCE%
  if  %AMDEP%
 @@ -46,7 +46,7 @@
 $(%FPFX%DEPMODE) $(depcomp) @AMDEPBACKSLASH@
  endif  %AMDEP%
 %LTCOMPILE% -c -o %LTOBJ% `test -f %SOURCE% || echo '$(srcdir)/'`%SOURCE%
 -endif %?LIBTOOL?%
 +endif %?LIBTOOL%
 
  ?GENERIC?%EXT%.obj:
  ?!GENERIC?%OBJOBJ%: %SOURCE%

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

Re: SGI mode depcomp breaks when '.' appears in source filenames twice

[Robert Boehne]

Thomas Dickey wrote:
 
 On Thu, Apr 05, 2001 at 10:32:02PM -0500, Raja R Harinath wrote:
  Well -- the whole idea is to remove the rule targets.  I know of only
  one use of multiple colons on a line -- in GNU make.  Even there,
  everything before a ':' is a rule target.  My comment "limited to the
  first ':'" may not be accurate, but I don't see any advantage to not
  always removing everything before a ':'.
 
 it sounds as if you're saying that
 
 rule ::
 action
 
 is GNU-make specific, which is not true, of course.
 
 --
 Thomas E. Dickey [EMAIL PROTECTED]
 http://dickey.his.com
 ftp://dickey.his.com

Thomas:

The question here applies to only the output of the SGI compiler's
automatic dependency generation, and perhaps other compilers that
use the same scheme(?).  If we had source for the SGI preprocessor
we could find out for certain, but I doubt that '::' will appear
anywhere in its output.
  I have attached a patch, made with the suggestions by Hari.
Unfortunately it wasn't made with cvs as I'm currently
in the midst of an outage. :(

Robert

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

--- depcomp Thu Apr  5 18:20:41 2001
+++ /usr/local/share/automake/depcomp   Wed Apr  4 10:58:22 2001
@@ -131,7 +131,7 @@
 # lines with more than a fixed number of characters (4096 in
 # IRIX 6.2 sed, 8192 in IRIX 6.5).
 tr ' ' '
-'  "$tmpdepfile" | sed 's/^.*\.o://' | tr '
+'  "$tmpdepfile" | sed 's/^[^\.]*\.o://' | tr '
 ' ' '  $depfile
 
 tr ' ' '

Re: SGI mode depcomp breaks when '.' appears in source filenames twice

[Robert Boehne]

I accidentally made the patch backwards, but it should
still work.  ;)

Tom Tromey wrote:
 
  "Raja" == Raja R Harinath [EMAIL PROTECTED] writes:
 
 Raja Whoops.  I forgot all about that.  I was thinking of
 Raja   foo.o bar.o: %.o: %.h; ...
 
 Multiple ":"s can appear on a line when using Windows, too.
 
 Raja Anyway, we are getting off-topic :-) The 'sed' rule under
 Raja question is applied to what's generated by an SGI compiler's
 Raja dependency-generator.
 
 I agree.  That's all that matters.  It probably doesn't generate "::"
 rules, or run on Windows, or anything like that.
 
 I haven't read the patch yet.  But if someone else with write access
 thinks it is ok, that's good enough for me.  It, or something, should
 go in.
 
 Tom

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

Re: Fixed? (Was: Conditionals in CVS Automake)

[Robert Boehne]

[EMAIL PROTECTED] wrote:
 
 I think I have it.  It's a very stupid typo :(
 
   
 
patchName: patch
 Type: Plain Text (text/plain)

Fixed.  :)  Thanks Akim!

Robert

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

Re: Conditionals in CVS Automake

[Robert Boehne]

Akim Demaille wrote:
 
  "Robert" == Robert Boehne [EMAIL PROTECTED] writes:
 
 Robert Hello all!  I've found a problem with conditional compilation
 Robert in the CVS version of Automake that was introduced some time
 Robert since March 4.  Multi-language-branch libtool fails 16 test
 Robert cases because the Makefile lacks the rules that it needs, to
 Robert build a target, they are commented out.
 
 I'm most probably responsible for this failure.  But I'd like to know
 whether one of the patches in the queue solves your issue.  Could you
 give a try to
 
 http://www.lrde.epita.fr/people/akim/download/this-is-not-automake-1.4e.tar.gz
 
 Thanks!

Akim:

Well, I've been trying to test your patches, but I'm running into
other problems.  If I install your version of automake, then
run the Libtool bootstrap script, configure and make, the -c option
that libtool passes to the compiler is gone.  This results in
errors because the compiler tries to link every file it compiles:

make[1]: Entering directory `/icarus/GNU/libtool/libltdl'
/bin/sh ./libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I. -g
-O2  -o ltdl.lo ltdl.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 ltdl.c  -fPIC -DPIC -o
.libs/ltdl.o
/usr/lib/crt1.o: In function `_start':
/usr/lib/crt1.o(.text+0x18): undefined reference to `main'
/tmp/ccSWYBux.o: In function `sys_dl_open':
/icarus/GNU/libtool/libltdl/ltdl.c:579: undefined reference to `dlopen'
/icarus/GNU/libtool/libltdl/ltdl.c:583: undefined reference to `dlerror'
/icarus/GNU/libtool/libltdl/ltdl.c:583: undefined reference to `dlerror'

If you'd like to reproduce this, get CVS multi-language-branch libtool
and CVS autoconf (I'm not sure that matters though).  I wish I could
tell you more about what the problem is.

Robert

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

Re: Conditionals in CVS Automake

[Robert Boehne]

Akim:

Ok, I hand-edited the Makefile.in's to add -c to the rule
that makes libtool *.lo objects, then reconfigured.
But the original problem exists in your patched version.
I'm looking into the differences between the Makefile.in's in
libtool's demo directory and I've noticed that the CVS
version has EXTRA_PROGRAMS defined twice, one with $(EXEEXT)
and one without.
  The following are two lines from CVS Automake Makefile.in

@BINARY_HELLDL_TRUE@am_helldl_OBJECTS = dlmain.$(OBJEXT)
helldl_OBJECTS = $(am_helldl_OBJECTS)

If @BINARY_HELLDL_TRUE@ is expanded to "#" then there is no
definition for $(am_helldl_OBJECTS), but it is used throughout
Makefile.in.  Does any of this set off alarm bells?

Robert


Robert Boehne wrote:
 
 Akim Demaille wrote:
 
   "Robert" == Robert Boehne [EMAIL PROTECTED] writes:
 
  Robert Hello all!  I've found a problem with conditional compilation
  Robert in the CVS version of Automake that was introduced some time
  Robert since March 4.  Multi-language-branch libtool fails 16 test
  Robert cases because the Makefile lacks the rules that it needs, to
  Robert build a target, they are commented out.
 
  I'm most probably responsible for this failure.  But I'd like to know
  whether one of the patches in the queue solves your issue.  Could you
  give a try to
 
  http://www.lrde.epita.fr/people/akim/download/this-is-not-automake-1.4e.tar.gz
 
  Thanks!
 
 Akim:
 
 Well, I've been trying to test your patches, but I'm running into
 other problems.  If I install your version of automake, then
 run the Libtool bootstrap script, configure and make, the -c option
 that libtool passes to the compiler is gone.  This results in
 errors because the compiler tries to link every file it compiles:
 
 make[1]: Entering directory `/icarus/GNU/libtool/libltdl'
 /bin/sh ./libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I. -g
 -O2  -o ltdl.lo ltdl.c
 gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 ltdl.c  -fPIC -DPIC -o
 .libs/ltdl.o
 /usr/lib/crt1.o: In function `_start':
 /usr/lib/crt1.o(.text+0x18): undefined reference to `main'
 /tmp/ccSWYBux.o: In function `sys_dl_open':
 /icarus/GNU/libtool/libltdl/ltdl.c:579: undefined reference to `dlopen'
 /icarus/GNU/libtool/libltdl/ltdl.c:583: undefined reference to `dlerror'
 /icarus/GNU/libtool/libltdl/ltdl.c:583: undefined reference to `dlerror'
 
 If you'd like to reproduce this, get CVS multi-language-branch libtool
 and CVS autoconf (I'm not sure that matters though).  I wish I could
 tell you more about what the problem is.
 
 Robert
 
 --
 Robert Boehne Software Engineer
 Ricardo Software   Chicago Technical Center
 TEL: (630)789-0003 x. 238
 FAX: (630)789-0127
 email:  [EMAIL PROTECTED]

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

Conditionals in CVS Automake

[Robert Boehne]

Hello all!

I've found a problem with conditional compilation in the
CVS version of Automake that was introduced some time since
March 4.  Multi-language-branch libtool fails 16 test cases
because the Makefile lacks the rules that it needs,
to build a target, they are commented out.

Could someone point me to the file(s) that could
be the culprit(s)?  I've not been able to track
this down as I'm not that familiar with the
entrails of Automake.

Thanks,

Rob

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

Re: How to install config.h

[Robert Boehne]

Assar Westerlund wrote:
 
 Robert Boehne [EMAIL PROTECTED] writes:
  I have a massive set of C++ libraries that use
  CVS libtool, autoconf and automake to build and install.
  Since users then need to have _all_ the header files
  they also need to have the configure generated config.h
 
  What is the "best" way to coerce Automake into installing
  config.h in $(prefix) ?
 
 I must caution against installing config.h.  You will collide with the
 potential same config.h and HAVE* et al defines that the application
 using your header files has figured out for itself.
 
 It's much preferable to make sure that the installed include-files do
 not depend on the autoconf'd parameters in any way.  If you really
 need to use the definitions that configure has figured out for you,
 it's much better, I think, to partial-evaluate so that instead of:
 

Thanks everyone for all the input!  I'm still in a bind though,
I would prefer NOT to install 12,000 atltered header files for
each platform, the package assumes binaries in a particular location
relative from the source directories, and I do agree that
"config.h" is probably the worst name I could install it as.
So I think the practial "solution" for now is to install
the header in $(prefix) as somthing other than "config.h".
Why?  I simply don't have the time or patience to re-arrange
the tens of thousands of source files into a GNU conforming
structure and then convince the maintainers that GNU automake
requires it.  People are comfortable with what is familiar,
I don't want to morph this project into somthing that the
originators won't recognize.
I'm gnuing my best here...

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

How to install config.h

[Robert Boehne]

I have a massive set of C++ libraries that use
CVS libtool, autoconf and automake to build and install.
Since users then need to have _all_ the header files
they also need to have the configure generated config.h

What is the "best" way to coerce Automake into installing
config.h in $(prefix) ?

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

Re: More about dependencies...

[Robert Boehne]

I have a similar problem, I have 'depcomp' in
$(top_srcdir)/make
and I have used
AC_CONFIG_AUX_DIR(make)
in 'configure.in'.  This doesn't work, but if I copy 'depcomp'
into $(top_srcdir) then it works.  Is there another step required
to get automake to find these auxiliary scripts?
I'm using CVS versions of Automake, Autoconf and Libtool (MLB).


Raja R Harinath wrote:
 
 Patrick Guio [EMAIL PROTECTED] writes:
  I refer to my earlier mails about problem with c++ dependencies. I don't
  know whether this is a bug but I found out why I could not make
  dependencies tracking working correctly.
  My code consists of several directories
 
  ~
  ~/src
  ~/tests
  and so on
 
  ~/Makefile.am does not contain so much
  ~/src is a directory with common c++ headers and source codes  while
  ~/tests contains source codes to build and test.
 
  When I run automake (-a -c --include-deps --force-missing) 'depcomp' were
  installed in ~/src and ~/tests but *not* in ~
  And there is the problem: when running configure I always got the messages
 
  checking dependency style of g++... none
  checking dependency style of gcc... none
 
  until I manually add a ~/depcomp
 
  Then
 
  checking dependency style of g++... gcc
  checking dependency style of gcc... gcc
 
  Why is a ~/depcomp necessary in ~/ since I don't have any code there?
 
 Actually it is needed only there, and not in the source directories.
 You just need one copy of the script per tree.  'automake' appears to
 be buggy.
 
 - Hari
 --
 Raja R Harinath -- [EMAIL PROTECTED]
 "When all else fails, read the instructions."  -- Cahn's Axiom
 "Our policy is, when in doubt, do the right thing."   -- Roy L Ash

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

Re: How to install config.h

[Robert Boehne]

Ossama Othman wrote:
 
 Hi Alexandre,
 
 On Thu, Oct 26, 2000 at 07:13:28PM -0200, Alexandre Oliva wrote:
  If you really want to have it installed, don't call it `config.h', or
  at least install it in include/your-package-name.  To accomplish
  that, use:
 
  pkginclude_HEADERS = config.h ...
 
  And use `#include your-package-name/config.h' in all other headers
  that include it.
 
 Ah!  Good call Alexandre!  Robert, please ignore my last post.
 Installing config.h in /usr/local/include, for example, would be
 obviously be bad idea. :-)
 
 BTW, I do exactly what Alexandre suggests in some of my own packages.
 It works out quite nicely.
 
 -Ossama

In my case I need to support several platforms in the same directory
tree,
not because I think this is a good idea, but I can't change the
package's
current framework.
So in my case users are encouraged to use NFS (or similar) for
installing
multiple architectures in the same directory tree.  i.e.:
$(prefix) = $(srcdir)/`uname`
That way users do not have to copy the 12,000 header files, yes that is
the right number, not a typo, and they aren't small either.
(I guess I'm more ambitious than wise.)
So to use the library users would add
-I$(prefix)/`uname` (for config.h) and -I$(prefix)/../inc (for the other
12,000)
to compile lines and -L$(prefix)/lib to link lines.
So you may think this is a train wreck, but it is better than
the csh scripts that are currently distributed -- no joke, csh!
With that said, is
pkginclude_HEADERS = config.h
a reasonable solution?

-- 
Robert Boehne   Very tired Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]