Build system improvements #2
Conversation
Make assumes that CC will be set to the active C compiler, so package managers automatically set CC accordingly. Read $CC instead of $GCC to take advantage of that.
Listing these targets in .PHONY forces make not to check for a corresponding file. This is a slight performance improvement and avoids unwanted behavior if the build directory ever has a file named 'all', 'clean', etc.
GNU make sets CURDIR to the value of the current directory. Use that instead of running a subshell to execute 'pwd'.
Most of the generated files follow one of a small number of general recipes. Replace the explicit per-file recipes with a pattern rule.
Users may want to set other optimization or debug levels, so split CFLAGS handling into two parts. The first part, which will be overridden by user environment variables, sets the default optimization and debug level for the project. The second part then applies values that should always be used. Also, move CPPFLAGS and LDFLAGS to their respective variables.
GNU make defines $RM as "rm -f", but using the indirect form allows the user to override it if needed.
Convert demo recipe to use existing $(PYTHON_CFLAGS) instead of calling python-config again.
An empty version is almost certainly a misspelled invocation. Disallow it.
Add $(srcdir) so that the caller can run "make -f $PATH_TO_SOURCE/Makefile srcdir=$PATH_TO_SOURCE". By default, srcdir will be blank, so this should have no effect on in-tree builds.
Python CFLAGS may contain settings that conflict with our own preferences, such as alternate optimization, debug, or warning choices. We only need to know where the headers were installed, so switch to --includes instead of --cflags.
Add an extra -I line for the non-flattened location, then change all inclusions to rely on the preprocessor search path to find the file. It is legal to specify a non-existent directory in the search path, so this will work with both old and new layouts.
Allow the user to change the name of the generated shared object by specifying an alternate $GCC_PYTHON_PLUGIN_SO on the command line.
Remove unnecessary import of six.py, so that gcc-python-plugin can be built (although not tested) without installing six.py.
|
Thanks. I ran into one slight issue with the changes: "make" and "make plugin" both finish with this line: "make -d "plugin" emits: Googling, http://darrendev.blogspot.com/2008/06/stopping-make-delete-intermediate-files.html suggests using ".SECONDARY:" |
|
There's some other discussion of this auto-deletion at: |
Per comment from David Malcolm, deleting autogenerated-*.c files is undesirable because it makes debugging more difficult. Switch to a static pattern rule to discourage Make from deleting these files.
|
Sorry, I did not realize that you wanted to keep those around. Yes, adding them to .SECONDARY should work. You could also change the rule to a static pattern rule. In both cases, they will be dropped in the object directory, rather than the source directory. Is this a problem for you? I have pushed a new commit onto the tip of master to use a static pattern rule, and confirmed locally that it prevents the autogenerated-*.c files from being deleted. I then built, packaged, and installed the plugin and confirmed that gdb is able to list the contents of the generated files by reading the installed copies. |
Build system improvements
As I offered on the mailing list last weekend, I have some improvements to the build system for gcc-python-plugin now in my master branch on github. I rebased the changes onto your master before pushing, so they should merge cleanly. The highlights are:
Let me know if you have any questions, requests for future improvements, etc.
I also have a Gentoo ebuild that can build and install it for the supported Python ABIs (2.7 and 3.2, currently). I can make that available if you want to include it in the source repository.