Thread: Makefile.global is kind of a pain
Just a notice: I tried really hard but Makefile.global as we know it can't work together with a fancy autoconf build system. We already know of the install-sh relative path problem. The next problem is that the automatic makefile remaking rules (see bottom of top GNUmakefile.in) can't be put into Makefile.global, so it really fails to do its job that is "include common stuff". What's worse, by including another makefile, each makefile would really have to worry about remaking Makefile.global as well. So as it is it's doing really little good. There are also several other more technical problems regarding relative paths and build vs source paths getting out of order, etc. So I thought I'd do the next best thing and apply the features that Autoconf bestowed upon us: output file concatenation. Instead of each Makefile including Makefile.global, each makefile is pasted together with a global makefile of sorts when it's created by config.status. That would look like this in configure.in: AC_OUTPUT( ... src/bin/psql/Makefile:config/top.mk:src/bin/psql/Makefile.in:config/bottom.mk ... ) (For various reasons a "top" global and a "bottom" global work best.) This approach seems to solve all of the mentioned problems. If you have no idea what I just meant, good. :) I'm currently plowing through the bin/ subtree, then you'll see. If you did, also good, feel free to comment. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
Peter Eisentraut <peter_e@gmx.net> writes:
> ... Instead of each
> Makefile including Makefile.global, each makefile is pasted together with
> a global makefile of sorts when it's created by config.status.
Hmm. My only objection to that is that it used to be possible to fix
some kinds of configure botches by hand-editing Makefile.global (which
after all is a configure output from Makefile.global.in). But now,
anything I don't like about what configure did is going to be physically
replicated in umpteen files, so if I don't understand autoconf well
enough to make configure do exactly what I wanted, I'm pretty much up
the creek.
What's so wrong with including Makefile.global? Maybe the system
won't know that an edit there requires a global rebuild, but I'd
rather have to do a "make clean"/"make all" after changing
Makefile.global than manually edit dozens upon dozens of makefiles
to get the same result.
Awhile back I was complaining that configure was dumping its results
into too many files already. This sounds like it will make that problem
many times worse.
regards, tom lane
Tom Lane writes: > Awhile back I was complaining that configure was dumping its results > into too many files already. If you're saying that configure should ideally only substitute things into Makefile.global and nowhere else then we're never going to have separate build directories, unless you know something that I don't. Every subdirectory where you build anything at all needs to have a Makefile.in. (Hint: How else will the build tree be created? How will the build tree find the source tree?) Yes, that will eventually make config.status run four times longer than it does now but that's the price to pay. If we don't want to do that then it'd be best that I know now. (Now that I spelled this out, I'm not sure myself whether that's worth it. Maybe we should forget about it and get rid of all *.in. It would certainly make my job easier.) -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> Awhile back I was complaining that configure was dumping its results
>> into too many files already.
> If you're saying that configure should ideally only substitute things into
> Makefile.global and nowhere else then we're never going to have separate
> build directories, unless you know something that I don't. Every
> subdirectory where you build anything at all needs to have a Makefile.in.
> (Hint: How else will the build tree be created? How will the build tree
> find the source tree?)
The separate-build-tree projects that I've used initialize the build
tree by doing, for each source directory containing C files (say,
src/foo/bar/)mkdir obj/foo/barln -s ../../../src/foo/bar/Makefile obj/foo/bar/Makefile
and then VPATH is set by the Makefile to ../../../src/foo/bar
(note this can be hard-wired in the Makefile, as long as it knows where
it lives in the source tree) and away you go. Of course files that
configure actually *needs* to make a modified copy of will go
right into the object tree. But you don't need to copy-and-edit
every Makefile just to get the VPATH info right.
This assumes that each object tree is a sibling of the src tree
(so you'd make .../pgsql/obj.linux, .../pgsql/obj.hpux, etc if you
are building for multiple architectures). If you need to build
somewhere else, a symlink or two can fake it.
> Yes, that will eventually make config.status run
> four times longer than it does now but that's the price to pay. If we
> don't want to do that then it'd be best that I know now.
I'd like to have the ability to have a separate build tree, but not at
the price of making configure run 4x longer --- especially not if it
runs 4x longer for everyone whether they want a separate build tree or
not. I think the villagers will be on your doorstep with pitchforks
if you try to push that through ;-). The nice thing about the above
approach is that if you aren't building in a separate tree, you don't
need to expend any work at all except on the files that really need
to be edited.
regards, tom lane
Tom Lane writes: > The separate-build-tree projects that I've used initialize the build > tree by doing, for each source directory containing C files (say, > src/foo/bar/) > mkdir obj/foo/bar > ln -s ../../../src/foo/bar/Makefile obj/foo/bar/Makefile > and then VPATH is set by the Makefile to ../../../src/foo/bar I think we might be able to do better: --Makefile-- subdir = src/bin/psql include ../../Makefile.global --Makefile.global-- top_srcdir = @top_srcdir@ # provided by autoconf srcdir = $(top_srcdir)/subdir VPATH = $(srcdir) ... --Makefile cont.-- # build stuff That way you can build in any directory. Well, that makes things a lot simpler. Then we really don't need any *.in files at all except for a select few. We'd just dump all @FOO@ things into Makefile.global. Of course I somehow have to hack up AC_PROG_INSTALL so it doesn't give a relative path to install-sh, but that can be done. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden