[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: install to top_builddir
Re: install to top_builddir
Tue, 5 Apr 2011 00:17:39 -0700
On Mon, Apr 4, 2011 at 10:56 PM, Ralf Wildenhues <address@hidden>wrote:
> Hello Reuben,
> * Reuben Hawkins wrote on Tue, Apr 05, 2011 at 05:51:52AM CEST:
> > In my build process, I need to have all the libraries copied to
> > $(top_builddir)/lib and all the bins to $(top_builddir)/bin and headers,
> Can you explain to us why you would need that to be done?
I'm replacing hand edited makefiles for a group of projects and developers
who are use to having all the binaries end up in the bin folder in the root
of the source tree. If there's a sample in SRC/demo/common/sample1, after
building, they'll expect to be able to run SRC/bin/sample1.
> > etc... Is there some de facto standard what to do this with automake?
> Extending the 'all' target can be done with the 'all-local' target.
> It (and any prerequisites it may have) are updated at 'make all' time
> (but the order in which it is run wrt. other prerequisites of 'all' is
> undefined in the parallel make case.
> > What I have now at the end of each of my Makefile.am's (which isn't doing
> > exactly what I want, but before I put more effort into it, I thought I'd
> > here) is...
> > publish:
> > $(MAKE) install DESTDIR="$(abs_builddir)/$(top_builddir)"
> > all: am-all publish
> You shouldn't override all. Use something like
> all-local: publish
> but also make 'publish' depend upon all files you are about to install,
> because otherwise parallel make may introduce ugly races with your two
> make instances competing for each other in updating them.
> Your publish rule commands have problems too: you don't override prefix,
> so that stuff ends up below $(abs_builddir)/$(top_builddir)$(prefix).
> That doesn't make sense to me (but since you don't explain what you
> actually need to do, I'm not sure). I'd have expected something like
> $(MAKE) $(AM_MAKEFLAGS) install DESTDIR= prefix="$(abs_top_builddir)"
> As to motivation: I suspect you want to reuse code for finding
> installed stuff similarly when looking for uninstalled stuff.
> It is often possible to make this easier by laying out the build
> tree similarly to the install tree (or multiple install trees,
> for large projects). But without more details, it's hard to give
> better advice.
Unfortunately, I'm unable to change the layout of the source tree. It's
decided by the committee.
The source is laid out something like this...
The source in SRC/core/internals/src/cpp compiles to a libtool library which
I'd like to copy to SRC/lib.
The source in SRC/demo/samples/sample1 compiles to a no install binary which
I'd like copied to SRC/bin
The libs, headers and stuff will still be installed as usual by 'make
> Hope that helps.
This info has been helpful. Thanks.