minor typo in manual

2005-06-07 Thread Toralf =?iso-8859-15?q?F=F6rster?=
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

In http://sources.redhat.com/automake/automake.html#Extending%20aclocal you 
wrote  would be expansed during the second definition but it should be 
expan*d*ed  isn't it ?

- -- 

Toralf
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCpWvLhyrlCH22naMRAlueAJ9afzMAhTdfB3jUAnVNRfAUCHMIegCfakkV
ojPzpYsrvtwGn4laNkY47Uw=
=Z7Pn
-END PGP SIGNATURE-




Re: How to extend automake?

2005-06-07 Thread Harald Dunkel
Tom Howard wrote:
 Hi Bruno,
 
 
 I used ax_add_mk_macro in ax_dist_rpm.m4 so that in my projects I can run
 
 make dist-rpm
 
 to create an rpm distribution.  Using these macros, all I have to add to
 the Makefile.am is @INCLUDE_MK@ at the end.
 

It would be pretty cool if Automake could append this
automagically when generating the Makefile.in files.


Regards

Harri




Re: How to extend automake?

2005-06-07 Thread Tom Howard
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Harri,

I used ax_add_mk_macro in ax_dist_rpm.m4 so that in my projects I can run

make dist-rpm

to create an rpm distribution.  Using these macros, all I have to add to
the Makefile.am is @INCLUDE_MK@ at the end.

 
 
 It would be pretty cool if Automake could append this
 automagically when generating the Makefile.in files.

Yes, yes it would, but at the moment my m4 macros are the only ones (at
least that I know of) that specifically put Makefile fragments into
$(top_builddir)/include.mk.  It would be a bit much to expect such a
feature to be added for one user.  If lots of other macros start
appearing that use AX_ADD_MK_MACRO, then it would make more sense.

Cheers,

- --
Tom Howard

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x433B299A
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCpVNUw1G4ZUM7KZoRAn2HAKCMXMtV6jUU8AfxCwNmJHyAyGuYagCfXpRG
9DizVPUSye2qekfZjqB5I+U=
=1DvW
-END PGP SIGNATURE-




Re: How to extend automake?

2005-06-07 Thread Thomas Degris

Hello,

make dist-deb, dist-ebuild, ... would be nice also and I think it would 
save lot of time for lot of people.


Thomas

Harald Dunkel wrote:


Tom Howard wrote:
 


Hi Bruno,


I used ax_add_mk_macro in ax_dist_rpm.m4 so that in my projects I can run

make dist-rpm

to create an rpm distribution.  Using these macros, all I have to add to
the Makefile.am is @INCLUDE_MK@ at the end.

   



It would be pretty cool if Automake could append this
automagically when generating the Makefile.in files.


Regards

Harri



 






back to directory dependencies

2005-06-07 Thread Baurzhan Ismagulov
Hello,

some time ago I asked a question on how to specify directory
dependencies. At that time I solved the problem by leaving just the
top-level Makefile.am and building all targets (binaries, libraries,
test programs) from it. In this way, I could specify explicit
dependencies between the binaries and libraries, no matter in which
directory they were located.

Now I want to integrate several project into the build system. The
directory hierarchy looks like this:

doc
drv
drv/d1
drv/d2
lib
lib/l1
lib/l2
src1
src2

d1, d2, l1, l2, src1, src2 are existing projects with Makefile or
configure.ac / Makefile.am. I want to leave them as they are and write a
Makefile that would build them in the necessary order according to the
dependencies.

So, how can I specify the build dependencies?

I could do something like that with a Makefile:

src1: l1
mkdir -p src1; \
cd src1; \
$(SRC)/configure; \
make; \
cd ..

l1:
mkdir -p lib/l1; \
cd lib/l1; \
$(SRC)/configure; \
make; \
cd ../..

But I want to use the advantages of autotools, like not having to
specify SRC on the command line, not having to create the directories in
the builddir, passing configure arguments to downstream configure
scripts (I need, e.g., CFLAGS and --host).

I would appreciate any advice!

Thanks in advance,
Baurzhan.




Re: How to extend automake?

2005-06-07 Thread Bruno Haible
Tom Howard wrote:
 The best way I've found to do this sort of think, is to create an
 autoconf macro that generates a Makefile fragment and use AC_SUBST_FILE
 on that.

Awesome! Terrific! Many many thanks for the hint.

Harald Dunkel wrote:
 It would be pretty cool if Automake could append this
 automagically when generating the Makefile.in files.

How could it know to which Makefile.ins it should append it? There are
typically several Makefile.ams for one configure.ac.

Bruno





Re: back to directory dependencies

2005-06-07 Thread Ralf Wildenhues
Hi Baurzhan,

* Baurzhan Ismagulov wrote on Tue, Jun 07, 2005 at 01:12:45PM CEST:
 
 Now I want to integrate several project into the build system. The
 directory hierarchy looks like this:
 
 doc
 drv
 drv/d1
 drv/d2
 lib
 lib/l1
 lib/l2
 src1
 src2
 
 d1, d2, l1, l2, src1, src2 are existing projects with Makefile or
 configure.ac / Makefile.am. I want to leave them as they are and write a
 Makefile that would build them in the necessary order according to the
 dependencies.
 
 So, how can I specify the build dependencies?

Put
  AC_CONFIG_SUBDIRS([d1 d2 l1 l2 src1 src2])
in toplevel configure.ac and
  SUBDIRS = d1 d2 l1 l2 src1 src2
in toplevel Makefile.am, in the order in which you want them configured
resp. built.

Read
  info Autoconf Subdirectories
  info Automake Subpackages
and more generally
  info Automake Directories.

Regards,
Ralf




using same automake conditional twice doesn't work?

2005-06-07 Thread Ed Hartnett

Howdy all!

The following automake file attempts to add two subdirs, fortran and
nf_test, if the BUILD_F77 automake conditional is true. But this
fails:

SUBDIRS = man

if BUILD_F77
SUBDIRS += fortran
endif

SUBDIRS += libsrc nc_test ncgen ncdump nctest

# If we're building the f77 API, test it too.
if BUILD_F77
SUBDIRS += nf_test
endif

The problem is that nf_test is not added to the end of the list, it is
added as the third item. So instead of trying to build in this order:

man fortran libsrc nc_test ncgen ncdump nctest nf_test

The resulting makefiles build in this order, which fails:

man fortran nf_test libsrc nc_test ncgen ncdump nctest 

Is this a know Automake feature, or am I doing something wrong?

What I do to get around this is define an extra automake conditional,
TEST_F77, at the same time I define BUILD_F77. By using first
BUILD_F77, then TEST_F77, automake does things in the correct order.

Any comments or observations would be helpful.

Thanks!

Ed

-- 
Ed Hartnett  -- [EMAIL PROTECTED]





Re: back to directory dependencies

2005-06-07 Thread Baurzhan Ismagulov
Hello Ralf,

thanks for your prompt answer!

On Tue, Jun 07, 2005 at 04:16:26PM +0200, Ralf Wildenhues wrote:
 Put
   AC_CONFIG_SUBDIRS([d1 d2 l1 l2 src1 src2])
 in toplevel configure.ac and
   SUBDIRS = d1 d2 l1 l2 src1 src2
 in toplevel Makefile.am, in the order in which you want them configured
 resp. built.

I've thought about SUBDIRS, but didn't know how I do AC_CONFIG_SUBDIRS.

But I have another problem with SUBDIRS. As I mentioned in the previous
thread, specifying -j starts building of l1 and src1 in parallel. l1
lasts longer, and src1 fails due to missing l1. So I think I really need
dependencies rather than sequence. What do you think?

With kind regards,
Baurzhan.




Re: using same automake conditional twice doesn't work?

2005-06-07 Thread Paul Smith
%% Ed Hartnett [EMAIL PROTECTED] writes:

  eh SUBDIRS = man

  eh if BUILD_F77
  eh SUBDIRS += fortran
  eh endif

  eh SUBDIRS += libsrc nc_test ncgen ncdump nctest

  eh # If we're building the f77 API, test it too.
  eh if BUILD_F77
  eh SUBDIRS += nf_test
  eh endif

There's a much better way to do this.  Try:

  if BUILD_F77
  PRE_SDIRS = fortran
  POST_SDIRS = nf_test
  endif

  SUBDIRS = man $(PRE_SDIRS) nc_test ncgen ncdump nctest $(POST_SDIRS)


Cheers!

-- 
---
 Paul D. Smith [EMAIL PROTECTED]   HASMAT--HA Software Mthds  Tools
 Please remain calm...I may be mad, but I am a professional. --Mad Scientist
---
   These are my opinions---Nortel Networks takes no responsibility for them.




Re: back to directory dependencies

2005-06-07 Thread Bob Friesenhahn

On Tue, 7 Jun 2005, Ralf Wildenhues wrote:


But I have another problem with SUBDIRS. As I mentioned in the previous
thread, specifying -j starts building of l1 and src1 in parallel. l1
lasts longer, and src1 fails due to missing l1. So I think I really need
dependencies rather than sequence. What do you think?


Which `make' does that?  I can't seem to get GNU make to do so.
(If it's GNU make, the quick'n'dirty solution would be to add
.NOTPARALLEL:
to the toplevel Makefile.am.  But that helps only for GNU make.)


Note that he said `-j', not `-j 2', or `-j 8'.  Without an argument -j 
is something close to infinite parallelism so it should indeed start 
considering the next directory as well.  If I use -j without an 
argument, the GraphicsMagick build blows up. Under Darwin, it seems 
that the blowup could be due to inability to fork.


Bob
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/




Re: How to extend automake?

2005-06-07 Thread Tom Howard
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Bruno,

Bruno Haible wrote:
 Tom Howard wrote:
 
The best way I've found to do this sort of think, is to create an
autoconf macro that generates a Makefile fragment and use AC_SUBST_FILE
on that.
 
 
 Awesome! Terrific! Many many thanks for the hint.

Glad I could help.

 Harald Dunkel wrote:
 
It would be pretty cool if Automake could append this
automagically when generating the Makefile.in files.
 
 
 How could it know to which Makefile.ins it should append it? There are
 typically several Makefile.ams for one configure.ac.

The only feasible answer is all of them.  This is what I do in my
projects, which means I also need to take extra care to make sure the
Makefile fragments work from any directory in the hierarchy.

Cheers,

- --
Tom Howard

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x433B299A
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCpmdIw1G4ZUM7KZoRAg6cAJ0WpxezlofMOd3slWnpNWAObnixsQCgnVga
8xeXtM74UkqKxEXM6VyNUSY=
=uLeQ
-END PGP SIGNATURE-