Thread: Makefile.global is kind of a pain

Makefile.global is kind of a pain

From
Peter Eisentraut
Date:
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



Re: Makefile.global is kind of a pain

From
Tom Lane
Date:
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


Re: Makefile.global is kind of a pain

From
Peter Eisentraut
Date:
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



Re: Makefile.global is kind of a pain

From
Tom Lane
Date:
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


Re: Makefile.global is kind of a pain

From
Peter Eisentraut
Date:
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