help-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Sune
Subject: Re: Need help with cleaning up a working GNU Autotools setup
Date: 9 Oct 2005 08:50:05 -0700
User-agent: G2/0.2

>  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
about the subject is required. I started with the autotools chain 2
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). Anyways, my research has paid
off and the result of it follows below. I give pointers and admit where
I was mistaken - fair enough?

> > Yes, that's exactly what I want. If I only add what you suggest then
> > 'make clean', 'make install' etc won't automagically be provided by
> > Automake.
>
> Why wouldn't they? I don't understand why you think so.
>
> > I guess I would also loose the configuration set up by
> > Autoconf(?).
>
> Again, I don't understand why you think so!
>

Wrong on my part, sorry.

> >> > 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. 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...

You suggest a non-standard solution to a common problem which will make
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. 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, ne
> >> mormally 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 surce directory.
>

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

> > Ok, now I understand(?). I don't think you have ever done this from
> > scratch. You have downloaded CVS distributions where the Makefile.in
> > has already been created for you. Right?
>
> Wrong.
>

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

bin_PROGRAMS = collections_test
collections_test_SOURCES = DynamicString.c test_main.c

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

>
> > You don't only create
> > makefiles by executing 'configure',
>
> You make the cnfigure file first by running autoconf!
>
> > what you do is examining the
> > installation target machine (your computer) to make the compiled target
> > portable to your machine (by adapting Makefiles according to config.h
> > and Makefile.in).
>
> No no. That's what running configure does.
>

Yes, yes, that's what I'm saying! It would have been more obvious if
you hadn't added a comment about something I already know and which is
...eh orthogonal. Nice to agree on something although you do your best
to sound as if we disagree.


> >> > 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.


>
> 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!

>
> > MY QUESTION:
> > How do I edit the above Makefile.am (and possibly configure.in) to
> > avoid getting object files and other targets mixed with my source
> > files?
>
> The way I told you to.

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

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

I will invest the rest of my time doing right. Good luck in the future!

LoL
Sune



reply via email to

[Prev in Thread] Current Thread [Next in Thread]