non-recursive makefile: last chance for objections
Proposal:
Switch to a single makefile in src/ that includes all the stuff previously in src/**/Makefile.am.
Top-level makefile continues to be recursive make. This simplifies data installation, and the benefits of changing aren't much for directories outside of src/**.
Use automake's `include' directive on blah/Makefile_insert.
Most existing blah/Makefile.am content goes to blah/Makefile_insert, e.g. blah_libblah_a_{CPPFLAGS,SOURCES,LDFLAGS,LDADD}.
Some "global" variable definitions move to src/Makefile.am: noinst_LIBRARIES, DISTCLEANFILES, EXTRA_DIST, EXTRA_PROGRAMS, TESTS, check_PROGRAMS.
INCLUDES/AM_CPPFLAGS become e.g. blah_libblah_a_CPPFLAGS (i.e. per-target instead of per-directory).
"Local" variable definitions (e.g. used for conditional compilation, e.g. win32_sources) go in src/blah/Makefile_insert, and acquire a `blah_' prefix. (The win32_sources variable from src/Makefile.am goes to src/Makefile_insert with no added prefix.)
src/Makefile.am contains:
+ include blah/Makefile_insert
+ Definitions for the aforementioned "global" variables.
+ dist-hook rule.
Advantages:
+ Can depend on things from other directories. E.g. some files in display/ depend on helper/sp-marshal.h having been built, and various */*-test programs depend on libraries in other directories (previously hacked with a `check-recursive: all-recursive' dependency in src/Makefile.am).
+ Compilation is expected to be faster:
- Fewer invocations of automake and make.
- Better parallelization is possible with make -j / make -l (e.g. when using distcc).
However, making CPPFLAGS per-target means much longer generated Makefile content. I haven't yet done timing tests (underway).
Disadvantages:
+ All files mentioned in the makefile fragments need to specify their directory. E.g. if blah/Makefile.am used to contain
libblah_a_SOURCES = \ foo.cpp foo.h
then blah/Makefile_insert will now contain
blah_libblah_a_SOURCES = \ blah/foo.cpp \ blah/foo.h
Any other advantages/disadvantages?
Checks to be done before switching:
+ `make install' creates same directory tree.
- Done. Some differences in the inkscape/inkview executable files, all other files bytewise-identical.
+ `make check' works.
- Done. Works. Hmm, haven't checked that all expected checks are getting run.
+ `make check' works immediately after `make clean'.
- Not yet checked.
+ `make distcheck' works.
- Not yet checked.
Any other checks to be done?
pjrm.
I totally agree. Although we would lose the idea of having a set of libs, this would greatly simplify the main build.
For those who still want to have their lib buildable and testable by itself, I would suggest that they continue having configure.in generate their Makefile, but do not have that makefile called by SUBDIRS= from the main build tree. Then you can still do your unit testing, but it will not affect the main tree.
Bob
Peter Moulder wrote:
Proposal:
Switch to a single makefile in src/ that includes all the stuff previously in src/**/Makefile.am.
Top-level makefile continues to be recursive make. This simplifies data installation, and the benefits of changing aren't much for directories outside of src/**.
Use automake's `include' directive on blah/Makefile_insert.
Most existing blah/Makefile.am content goes to blah/Makefile_insert, e.g. blah_libblah_a_{CPPFLAGS,SOURCES,LDFLAGS,LDADD}.
Some "global" variable definitions move to src/Makefile.am: noinst_LIBRARIES, DISTCLEANFILES, EXTRA_DIST, EXTRA_PROGRAMS, TESTS, check_PROGRAMS.
INCLUDES/AM_CPPFLAGS become e.g. blah_libblah_a_CPPFLAGS (i.e. per-target instead of per-directory).
"Local" variable definitions (e.g. used for conditional compilation, e.g. win32_sources) go in src/blah/Makefile_insert, and acquire a `blah_' prefix. (The win32_sources variable from src/Makefile.am goes to src/Makefile_insert with no added prefix.)
src/Makefile.am contains:
include blah/Makefile_insert
Definitions for the aforementioned "global" variables.
dist-hook rule.
Advantages:
Can depend on things from other directories. E.g. some files in display/ depend on helper/sp-marshal.h having been built, and various */*-test programs depend on libraries in other directories (previously hacked with a `check-recursive: all-recursive' dependency in src/Makefile.am).
Compilation is expected to be faster:
Fewer invocations of automake and make.
Better parallelization is possible with make -j / make -l (e.g.
when using distcc).
However, making CPPFLAGS per-target means much longer generated Makefile content. I haven't yet done timing tests (underway).
Disadvantages:
All files mentioned in the makefile fragments need to specify their directory. E.g. if blah/Makefile.am used to contain
libblah_a_SOURCES = \ foo.cpp foo.h
then blah/Makefile_insert will now contain
blah_libblah_a_SOURCES = \ blah/foo.cpp \ blah/foo.h
Any other advantages/disadvantages?
Checks to be done before switching:
`make install' creates same directory tree.
- Done. Some differences in the inkscape/inkview executable files, all other files bytewise-identical.
`make check' works.
- Done. Works. Hmm, haven't checked that all expected checks are getting run.
`make check' works immediately after `make clean'.
- Not yet checked.
`make distcheck' works.
- Not yet checked.
Any other checks to be done?
pjrm.
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Wed, Apr 21, 2004 at 09:47:44AM -0500, Bob Jamison wrote:
Although we would lose the idea of having a set of libs,
Nothing changes about what .a libs we build (src/libnr/libnr.a etc.).
For those who still want to have their lib buildable and testable by itself [for unit testing]
The existing unit test framework remains. (We may move some of utest.h to a .cpp file now that we can depend on things in other directories, and we can get rid of the check-recursive: all-recursive hack.)
See also the discussion on convenience stub makefiles, elsewhere in this thread.
Are these provisions already sufficient to address concern re unit-testing?
pjrm.
Heh! No need to discuss, Peter! I'm agreeing with you 100%. ;-) I think that this is a wonderful idea. Good work.
Peter Moulder wrote:
On Wed, Apr 21, 2004 at 09:47:44AM -0500, Bob Jamison wrote:
Although we would lose the idea of having a set of libs,
Nothing changes about what .a libs we build (src/libnr/libnr.a etc.).
For those who still want to have their lib buildable and testable by itself [for unit testing]
The existing unit test framework remains. (We may move some of utest.h to a .cpp file now that we can depend on things in other directories, and we can get rid of the check-recursive: all-recursive hack.)
See also the discussion on convenience stub makefiles, elsewhere in this thread.
Are these provisions already sufficient to address concern re unit-testing?
pjrm.
On Wed, 2004-04-21 at 10:32, Peter Moulder wrote:
Any other advantages/disadvantages?
Hmm, is there any way to (easily) construct stub makefiles so that it isn't necessary to cd up a couple levels before you can run 'make'?
-mental
On Wed, Apr 21, 2004 at 01:18:11PM -0400, MenTaLguY wrote:
On Wed, 2004-04-21 at 10:32, Peter Moulder wrote:
Any other advantages/disadvantages?
Hmm, is there any way to (easily) construct stub makefiles so that it isn't necessary to cd up a couple levels before you can run 'make'?
Yes and no. src/blah/makefile can be of the form:
# Explicit so that it's the default rule. all: cd .. && $(MAKE) blah/all
%: cd .. && $(MAKE) blah/$@
.PHONY: all
I've already inserted a blah/all rule into src/blah/Makefile_insert for all blah. This works for `all' and for all real files (libblah.a), but `clean' may be trickier, due to different placement of object files (src/blah_libblah_a-foo.o instead of src/blah/foo.o). Maybe can be approximated with `rm -f $(blah_libblah_a_OBJECTS) blah/libblah.a' or `rm -f blah_libblah_a* blah/libblah.a'. For the purposes of deciding whether to go ahead with this change, let's conservatively assume that we don't succeed in implementing `clean': if ppl consider this a show-stopper then I'll see what I can implement before deciding on whether to switch. Similarly let me know if there are other rules that people consider important in this stub makefile.
On choice of name for src/blah/makefile: I deliberately wrote lower-case to facilitate tab completion. I'm currently considering not having them generated by configure, though that means requiring something like gnu make: e.g. it requires that $(MAKE) be defined, and it's desirable that `%' is understood. Explicitly setting the value of MAKE seems to destroy its special meaning. These stub makefiles are only for convenience, and are principally intended for developers, so I don't think it a problem for them not to be as portable as the generated src/Makefile. Variations:
- Have them generated by configure, which detects whether or not explicit MAKE = ... is required (`@SET_MAKE@'). The only disadvantages are having a few makefile.in files around and a bit of extra work & output from configure/config.status.
- Name them GNUmakefile so that non-gnu make programs don't even see the makefile. Avoids the possibility of a confusing error message if MAKE isn't defined (in which case that make will try to execute blah/something).
- Explicitly set `MAKE = make' in the makefile. The magic value of $(MAKE) in gnu make would be lost. May interfere with things like `make -n' working (I haven't tried).
pjrm.
On Thu, Apr 22, 2004 at 11:31:55AM +1000, Peter Moulder wrote:
On choice of name for src/blah/makefile: I deliberately wrote lower-case
BTW, when making changes or new areas where files will get auto-generated, please add them to the .cvsignore file as well. I've gone and done that for .dirstamp and makefile in all the subdirectories.
Other than that, it looks great. :)
On Thu, Apr 22, 2004 at 02:19:48PM -0700, Kees Cook wrote:
BTW, when making changes or new areas where files will get auto-generated, please add them to the .cvsignore file as well. I've gone and done that for .dirstamp and makefile in all the subdirectories.
You beat me to it, so I got conflicts when I cvs up'ed :)
pjrm.
On Thu, Apr 22, 2004 at 12:32:24AM +1000, Peter Moulder wrote:
Advantages:
Can depend on things from other directories. E.g. some files in display/ depend on helper/sp-marshal.h having been built, and various */*-test programs depend on libraries in other directories (previously hacked with a `check-recursive: all-recursive' dependency in src/Makefile.am).
Compilation is expected to be faster:
Fewer invocations of automake and make.
Better parallelization is possible with make -j / make -l (e.g.
when using distcc).
However, making CPPFLAGS per-target means much longer generated Makefile content. I haven't yet done timing tests (underway).Disadvantages:
All files mentioned in the makefile fragments need to specify their directory. E.g. if blah/Makefile.am used to contain
libblah_a_SOURCES = \ foo.cpp foo.h
then blah/Makefile_insert will now contain
blah_libblah_a_SOURCES = \ blah/foo.cpp \
blah/foo.h
+ Only partial support for typing `make whatever' from inside src/blah/ directories.
+ Small amount of extra clutter: an extra makefile per subdirectory of src (or lose all support for `make whatever' from inside subdirectories of src); and src has both Makefile.am and Makefile_insert.
+ Makefile_insert scheme will be unfamiliar to most new developers.
+ Easier to have problems due to variables in one Makefile_insert having an effect on other parts. automake detects the most common errors (two variables with the same name).
+ Looks like we'll want to remove support for automake1.6 if we go to non-recursive makefiles. However, automake1.7 has been around since about 2002-09-25, and automake1.8 is already available.
(Problems with automake1.6: problem if we have two .cpp files of same name in different directories. Appears not to handle blah_libblah_a_CPPFLAGS properly.)
Any other advantages/disadvantages?
Checks to be done before switching:
`make install' creates same directory tree.
- Done. Some differences in the inkscape/inkview executable files, all other files bytewise-identical.
`make check' works.
- Done. Works. Hmm, haven't checked that all expected checks are getting run.
`make check' works immediately after `make clean'.
- Not yet checked.
`make distcheck' works.
- Not yet checked.
+ Test with automake1.7, 1.8. Probably just testing `make && make check'.
- automake1.6 seems not to work well enough (see above).
+ Check that warnings/errors are parsed ok by xemacs21. (Other editors are likely to be ok iff xemacs21 has no problem.)
+ Try gdb, to check that it has no problem with filenames.
Any other checks to be done?
pjrm.
participants (4)
-
Bob Jamison -
Kees Cook -
MenTaLguY -
Peter Moulder