Re: Need help with cleaning up a working GNU Autotools setup

[Peter T. Breuer]

In comp.os.linux.development.system Sune <sune_ahlgren@hotmail.com> wrote:
>>  Anyway, what is certain is that you can't talk sensibly about
>> your problem, and as a result people can't talk to you.

> To be able to ask the proper questions, a fair amount of knowledge

A minimal amount.  Thinking about it I think the root problem is maybe
that you don't know how to write makefiles and that you are therefore
wanting to use autotools to write your makefiles for you.

That would explain a possible fear element in your behaviour that I
suspect exists and is partly responsible for what looks like
irrationality from here. 

Autotools don't write makefiles FOR you, they HELP you write a
makefile.


> about the subject is required. I started with the autotools chain 2

Aha. That's the problem too. One doesn't "start with autotools". One
starts with a makefile set, and considers how to abstract out of it
or improve it with factors that could better be put into it in a more
general way by autotools.

> days ago and of course my questions will not be razor sharp and to the
> point (although the GNU guys immediately understood and gave me 2
> chrystal clear 10 sentence explanations).

You think! I still don't know what you want because you say you don't want
to compile outside the source hirearchy yet every example you give of what
you want to do is compile outside the source hierarchy.

Anyway, the gnu people have never managed to say anything clearly, about
autotools or anything else! So I doubt your statement. If they were so
clear you would be busy gaining an awful lot from "info autconf"!
(that's all I've ever bothered reading, and it contains everything I
have needed to know so far).


> Anyways, my research has paid
> off and the result of it follows below. I give pointers and admit where
> I was mistaken - fair enough?

Sure!


>> >> > If I only add what you suggest then
>> >>
>> >> What did I suggest? Surely only use of VPATH.
>> >>
>> > You suggested that the following be done for each sub directory:
>>
>> > cd collections/bin
>> >    make -f ../../global/Makefile target VPATH=../../global/
>>

> Wrong on your part; the solution that is. This a situation where VPATH
> should _not_ be used.

If you want to compile outside of the source tree, VPATH _must_ be used
because "that's what it's for".  It tells make where to look for the
source files, because they're not going to be in the compile directory! 
By definition.

So what is this "situation"?


> I read this in a really nice paper I found after
> getting in contact with the gnu guys. The guy who wrote this paper
> (when and why VPATH should be used) is a GNU guy and was heavily
> involved in implementing GNU make. I could have given you the link, but
> I leave it up to you and your neuron...

Thanks, but the only paper I know concerning make is something like
"recursive make considered dangerous", with which I agree completely.

However, you may or may not be requiring a recursive make! It's not
been possible to tell from your description thus far. Your fears about
not being able to make clean seem to express a desire to do a
_recursive_ make clean. There is of course nothing stopping you doing a
simple find . -type d -exec make clean \; from the top!


> You suggest a non-standard solution to a common problem which will make

And what is this problem? You haven't managed to say!

> my project hard to understand by people participating or taking over
> after me. The standard way of doing this has been communicated to me by
> the GNU guys in a very clear and concise way.

As I said - you aren't clear, and they never are clear.

> Again, since you imply
> that my unwillingness to implement something I don't fully understand
> or agree with stems from a brain damage, I will let you continue to do
> wrong and annoy your fellow programmers.

>> > Instead of just execute a plain 'make' from the base directory 'rsd/'
>>
>> No - that's what executing the make at the top DOES. It's not "instead
>> of it".
>>

> My mistake, I'm sorry.

>> >> I don't understand - when compiling outside the source directory, one
>> >> normally makes a build/ subdir, cds there, then runs ../configure
>> >> there in orser to make a Makefile.  Then one runs make against that
>> >> Makefile, with VPATH set to the source directory.

> Wrong on your part. You suggest a non-standard solution [see above]...

That IS the standard solution, at least as far as the use of VPATH goes.
An alternative to using a single top level Makefile is to build
a makefile in each build subdir using autoconf. That's fine, but it's
nothing to do with the methodology itself - simply your choice.

You can also populate the build dir with sources if you wish! But if
you don't, then either you use VPATH or you explicitly calculate a full
path for each source. 

You can also do the make in the source directory and redirect the object
files (again, that's trivial). But that's messy and means that you have
to sit there and do a full make, then move or copy the results, or be
careful with the library builds in terms of pointing them to the right
places both for input and output.  Not good. Experience says this is a
nono. Make is intended to build in the directory it is IN. It's object
oriented, in that sense.

>> Wrong.

> Wrong on your part. If you claim that this is _not_ a Makefile.am:

It isn't.


> bin_PROGRAMS = collections_test
> collections_test_SOURCES = DynamicString.c test_main.c

This is simply a Makefile.  There is nothing (except possibly reserved
variables names) in there that makes it a makefile.am.  Makefile.am will
have special make-illegal variables in it that are _substituted_ in
order to (eventually) get a Makefile.  Those variables have the form
"@foo@".  You will see, for example:

  srcdir = @srcdir@
  top_srcdir = @top_srcdir@
  top_builddir = ..
  VPATH = $(srcdir)

and the configure run produces the real makefile. That's the whole
point! If you don't do that, you are not using the capabilities
appropriately.


> there is _no way_ you have ever written a Makefile.am.

:-).


>> >> > I'm afraid that if I start to add parts outside the Autotools
>> >> > environment, I may end up in a maintenance nightmare.
>> >>
>> >> I don't understand. Nobody is talking abut "adding parts".

> Wrong again on your part! Adding parts (in a non-standard way, see
> above) is what you ask me to do. Remember this?

>  for i in $(SUBDIRS); do $(MAKE) -C $$i -f $(TOPDIR)/Makefile $@; done

> With a proper autotool chain approach this is completely unnecessary.

It's not "unnecessary", it is correct. You can create it using some
autotools constructs (for example by designating the subdirs via an ls
in the configure run, and exporting the SUBDIRS variable) but it
is what will be there!

You seem to have less concept that you are programming than is useful to
maintain ths cnversation. I repeat - autotools HELP you build makefiles.
They do not obviate the need for you to build a makefile.

>> Of course not!  Where do you get this idea from? There is ONE
>> subdirectory in which you do the build. It's called build/, usually!
>> It contains a mirror dir hierarchy which starts off empty and gets
>> filled with makefiles by the configure run, and then filled by
>> .o files from the make.

> This I have now understood and agree with.

>>
>> > If I use Autotools and something changes in my compile environment
>> > (which in the beginning of the project will happen quite often), I only
>> > add a subdir in the base Makefile.am, and add a Makefile.am in the new
>> > subdir and execute 'autoreconf'. Voila! I can execute a simple make
>> > from the base directory again.
>>
>> That is completely an orthognal question!

> This not a question (a subject perhaps); it's my motivation for not
> wanting to implement anything in a half-assed way.

>>
>>
>> > bin_PROGRAMS = collections_test
>> > collections_test_SOURCES = DynamicString.c test_main.c
>>
>> This is not a Makefile.am. It contain no variables to be supplied by
>> the configure run.

> Once again, wrong on your part!

That any Makefile is also a Makefile.am is pointless to mention, but
your example contains nothing syntactically that marks it as Makefile.am
rather than a Makefile (except possibly reserved make variable names - I
don't know if they are reserved or not).  Try it - you will find that
make is happy with it as a makefile!  Real Makefile.am contain
constructs that are not digestible by make such as @foo@ variables that
are filled in and converted to proper makefile constructs by the
./configure run.


> Wrong again on your part. The way you suggest is messy, unnessecary -
> plain wrong!

It's plain correct, and perfectly normal, and a one liner!

> What hasn't been mentioned here, I leave up to your neuron and your
> millions of therapists!

Since it's evident that you are busy fantasizing away, I leave it to
your imagination to proceed.


Peter1