Re: Non-recursive make & intermediate objects

2003-11-21 Thread Robert Collins 
On Sat, 2003-11-22 at 07:12, Bob Friesenhahn wrote:

> So this bug is only present if SUBDIRS is used to cause the Makefile
> to also have a recursive aspect.

Yes - which projects that include other projects will need. Or for
things like test scripts, I find throwing them in a sandbox of sorts
much easier than a full recursive makefile - at least until I get back
to that proof of concept.

Rob
-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part

Re: Non-recursive make & intermediate objects

2003-11-21 Thread Bob Friesenhahn 
On Sat, 22 Nov 2003, Robert Collins wrote:
> >
> > Please move the clean bug up in the priority level.  Automake has a
> > non-recursive user now. :-)
>
> We've had them for ages - I've been using it for 2 years now in
> progressive increasing sizes I keep meaning to get back to my
> transforming include patch
> (http://sources.redhat.com/ml/automake/2001-08/msg00112.html) to make
> authoring them less unpleasant.
>
> PR 373 is the bug I was referring to on clean - it's a general race
> condition.
> http://mail.gnu.org/archive/html/automake/2003-07/msg00064.html is a
> relevant email in this list archives.

So this bug is only present if SUBDIRS is used to cause the Makefile
to also have a recursive aspect.

> > I suspect/believe that libtool will have some problems as well.
>
> libtool has worked fine for me, with non recursive make for 2 years now.
> Not to say there are not issues to find :}.

Right.  I have not noticed a libtool problem when using the recursive
make.  I am not using SUBDIRS so the only issue I have noticed thus
far is odd-naming of intermediate objects.

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

Re: Non-recursive make & intermediate objects

2003-11-21 Thread Robert Collins 
On Thu, 2003-11-20 at 09:50, Bob Friesenhahn wrote:
> On Thu, 20 Nov 2003, Robert Collins wrote:
> 
> > subdir_objects in your automake options.
> >
> > Problem is, there is a design headache that makes recursive clean fail
> > with this approach - I forget the bug #, but it's on my todo, waay down
> > there :p.
> 
> Ahhh, subdir-objects.  Since this is so important to non-recursive
> makes, it would be useful if it was referenced in the "An Alternative
> Approach to Subdirectories" section of the documentation.
> 
> Please move the clean bug up in the priority level.  Automake has a
> non-recursive user now. :-)

We've had them for ages - I've been using it for 2 years now in
progressive increasing sizes I keep meaning to get back to my
transforming include patch
(http://sources.redhat.com/ml/automake/2001-08/msg00112.html) to make
authoring them less unpleasant.

PR 373 is the bug I was referring to on clean - it's a general race
condition.
http://mail.gnu.org/archive/html/automake/2003-07/msg00064.html is a
relevant email in this list archives.

> I suspect/believe that libtool will have some problems as well.

libtool has worked fine for me, with non recursive make for 2 years now.
Not to say there are not issues to find :}.

Rob

-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part

Re: Non-recursive make & intermediate objects

2003-11-20 Thread Gary V. Vaughan 

On Wed, 19 Nov 2003 16:50:23 -0600 (CST), "Bob Friesenhahn"
<[EMAIL PROTECTED]> said:
> On Thu, 20 Nov 2003, Robert Collins wrote:
> 
> > subdir_objects in your automake options.
> >
> > Problem is, there is a design headache that makes recursive clean fail
> > with this approach - I forget the bug #, but it's on my todo, waay down
> > there :p.
> 
> Ahhh, subdir-objects.  Since this is so important to non-recursive
> makes, it would be useful if it was referenced in the "An Alternative
> Approach to Subdirectories" section of the documentation.
> 
> Please move the clean bug up in the priority level.  Automake has a
> non-recursive user now. :-)
> 
> I suspect/believe that libtool will have some problems as well.

Libtool has only one Makefile.am per configure.ac already, but I did trip
over a few problems when I tried to convert M4 to a non-recursive
Makefile.  I'd like to convert it now, but there are some issues that I
reported (maybe this is one actually).

Cheers,
Gary.
-- 
  ())_.  Gary V. Vaughangary@(lilith.warpmail.net|gnu.org)
  ( '/   Research Scientist http://www.oranda.demon.co.uk   ,_())
  / )=   GNU Hacker http://www.gnu.org/software/libtool  \' 
  `&
`(_~)_   Tech' Author   http://sources.redhat.com/autobook  
=`---d__/

Re: Non-recursive make & intermediate objects

2003-11-19 Thread Kevin P. Fleming 
Bob Friesenhahn wrote:

Please move the clean bug up in the priority level.  Automake has a
non-recursive user now. :-)
More than one :-) My project also uses non-recursive Makefile to build a 
bunch of libraries (one normal, about 30 plugin modules) and a couple of 
other directories of executables, as well as includes and documentation.

Re: Non-recursive make & intermediate objects

2003-11-19 Thread Bob Friesenhahn 
On Thu, 20 Nov 2003, Robert Collins wrote:

> subdir_objects in your automake options.
>
> Problem is, there is a design headache that makes recursive clean fail
> with this approach - I forget the bug #, but it's on my todo, waay down
> there :p.

Ahhh, subdir-objects.  Since this is so important to non-recursive
makes, it would be useful if it was referenced in the "An Alternative
Approach to Subdirectories" section of the documentation.

Please move the clean bug up in the priority level.  Automake has a
non-recursive user now. :-)

I suspect/believe that libtool will have some problems as well.

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

Re: Non-recursive make & intermediate objects

2003-11-19 Thread Robert Collins 
On Thu, 2003-11-20 at 09:04, Bob Friesenhahn wrote:
> Using Automake 1.7.9, I am attempting to create a single Makefile.am
> which is capable of building all of the libraries used by the project.
> The source files to the project are located in subdirectories, and the
> output libraries should also be located in subdirectories.  The
> objective is to replace an existing recursive build.
> 
> Using a rule like:
> 
> noinst_LIBRARIES = libs/somedir/libfoo.a
> libs_somedir_libfoo_a_SOURCES=foo.cc
> 
> and then inpecting the output of 'make -n' (and the generated
> Makefile), I see evidence that the build will put all .Po files in a
> .deps subdirectory under the Makefile.am, and all the .o files in the
> same directory as Makefile.am.  This approach seems quite wrong to me
> since it is quite possible that libraries and applications may use
> similarly named source files.  Intermediate files should be placed
> either under the directory where the library is placed, or in the
> directory where the source files live.  An even better solution would
> allow the user to specify where intermediate files are placed on a
> per-library and per application basis.

subdir_objects in your automake options.

Problem is, there is a design headache that makes recursive clean fail
with this approach - I forget the bug #, but it's on my todo, waay down
there :p.

Rob