RE: Trying to improve our dependency tracking

[James Willenbring]

Ralf,

Thanks for your reply.  Based on your explanation, I think what we are
trying to do is probably not possible.  In your example below, 

if NEED_LIBA
libb_la_LIBADD += ../liba/liba.la
endif

We would want to replace ../liba/liba.la with another variable.  We have
multiple layers of dependencies and we only want each package to have to
know about its direct dependencies.  That way if liba.la's dependencies
change, libb doesn't have to care about it.

To show you exactly what we are trying, I have attached 4 files.

1) configure.ac (note that Makefile.export.teuchos.in is under the control
of a sibling configure process)
2) Makefile.include.am (could be a Makefile.am, not sure why it isn't - this
shows us attempting to use the EPETRA_DEPS value)
3) Makefile.export.epetra.in (sets the EPETRA_DEPS value conditional on
whether or not Teuchos is built - note TEUCHOS_DEPS is unconditionally
listed in EPETRA_DEPS, but Makefile.export.teuchos.in is only conditionally
included in Makefile.export.epetra.in)
4) Makefile.export.teuchos.in (sets the TEUCHOS_DEPS value that is used in
the value of EPETRA_DEPS)

If I manually move the include directives in the generated Makefile's, this
works for me, but otherwise the *_DEPS values are resolved before the
inclusions are processed, and are therefore empty.

Thanks

Jim

-Original Message-
From: Ralf Wildenhues [mailto:[EMAIL PROTECTED] 
Sent: Monday, May 05, 2008 10:25 PM
To: Willenbring, James M
Cc: automake@gnu.org
Subject: Re: Trying to improve our dependency tracking

Hello James,

* James Willenbring wrote on Thu, May 01, 2008 at 10:51:11PM CEST:
 When I add

 myexe_DEPENDENCIES = $(PACKAGEA_DEPENDENCIES)

 $(PACKAGEA_DEPENDENCIES) is not resolved before dependencies are checked.
 Despite the fact that I put the include directive at the top of the
 Makefile.am, it shows up at the bottom of the Makefile.  If I manually
move
 the include directive higher in the makefile (but below the definition of
 top_builddir), everything works as I would hope.

Can you show an example Makefile.am plus configure.ac that exposes this
problem?

 Does anyone have any suggestions for fixing this problem or for a
different
 approach I should take for dependency tracking?

In general, I try to let automake compute dependencies as much as
possible.  For example, it cannot see the dependency with this:

-- snip libb/configure.ac --
AC_SUBST([LIBA], [../liba/liba.la])

-- snip libb/Makefile.am --
libb_la_LIBADD = $(LIBA)
# next line needed because automake cannot see through substitution
libb_la_DEPENDENCIES = $(LIBA)


OTOH, it *can* compute the dependency with conditionals:

-- snip libb/configure.ac --
AM_CONDITIONAL([NEED_LIBA], [test -n $need_liba])

-- snip libb/Makefile.am --
if NEED_LIBA
libb_la_LIBADD += ../liba/liba.la
endif
# No *_DEPENDENCIES needed in this example.


Hope that helps.

Cheers,
Ralf



Makefile.export.teuchos.in
Description: Binary data


configure.ac
Description: Binary data


Makefile.export.epetra.in
Description: Binary data


Makefile.include.am
Description: Binary data

Automake TESTS question

[John Calcote]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I've got a simple unit test scenario - I want to run my program and
verify some text on its single output line. In a makefile, I might do this:

check:
myprog | grep myprog text
@echo PASSED!

In Automake, what's the simplest way to do this? I've found this way:

EXTRA_DIST = greptest.sh
TESTS = greptest.sh

But this requires me to:

1) Actually HAVE a one-line script file called greptest.sh as part of
my package.

2) Use the EXTRA_DIST line. Why is this? Can't Automake tell from the
TESTS line that this is a file I need in my distribution?

In my experiments, I've also discovered this method:

TESTS_ENVIRONMENT = $(SHELL)
TESTS = greptest.sh

greptest.sh:
   echo 'myprog | grep myprog text'  greptest.sh

clean-local:
   -rm greptest.sh

But this seems overly complex for a one-liner. In addition, I had to add
the TESTS_ENVIRONMENT line because I could NOT get chmod to set
greptest.sh to executable. The make utility just seemed to ignore the
command, if I added it after the echo line.

The clean-local line was necessary in this case because make distcheck
 complains that greptest.sh was left lying around, and the - in front
of rm was necessary because otherwise make clean will fail if make
check isn't run first.

Anyone know of a more concise way of doing this? Frankly, I'd like to
just run the script inline somewhere, but I can't see a way to do it
with Automake. It wants all TESTS to be real files.

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

iD8DBQFILfX4dcgqmRY/OH8RAsSPAJ4/q1yaj4REwuqJgH5GKyV3ywBZzgCfUfw9
fHr/e/1kvwJzC+DVHDUZZyc=
=eJNi
-END PGP SIGNATURE-

libtool wrapper vs $cwd

[Dan McMahill]

Hello,

I helped out with a a build system and switching to libtool for a shared 
library and am now having the following problem.  After building but 
before installing, the program used to be able to be tested by


cd foo-x.y/src
./myprog

Unfortunately, it was keying off of the directory part of argv[0] to 
help find a file which must be read when the program runs but now 
argv[0] includes .libs/ due to libtool.


There is an environment variable which can be set that will tell myprog 
to look somewhere else for this file.  Is there anyway to cause the 
libtool wrapper script, src/myprog, to set this variable automatically? 
 If not, any suggestions on the best way to deal with programs which 
might use the directory of argv[0] when testing with the libtool 
generated wrapper script?


Thanks
-Dan