In thinking again about Pd's build system(s) while working on the Windows build, I think there is a good solution which would allow combining both the Makefiles and autoconf.
As far as I see it, the pros/cons of the various systems we have now are:
* makefiles: easy to understand & fast, less adaptable / configurable * autotools: easy to use and configurable, harder to understand, lots of files
I think we definitely want to pros of both: easy to understand, easy to use, configurable.
Since the autotools (autoconf. automake, etc) are built around make already, it's not like these systems are mutually exclusive. The Makefile.am automaker files are used to generate Makefile.in files which are used to generate the Makefiles.
I propose that we transition from using automake directly and write our own Makefile.ins. This way more of the actually logic is shifted to the Makefile.in files themselves while we still get the configuration variables from the configure script. The con for this is we lose a lot of the boilerplate stuff that automaker handles but would gain Makefiles which basically look like Miller's original makefiles.
Additionally, the cross platform stuff like file lists and install rules, etc could be defined in a shared Makefile and we keep the platform specific makefiles. Last, we would be able to handle custom rules & approaches by not having to fight automake for things like generating binaries in the bin folder and making a "sourceful" release build in place with ./configure.
There are a number of projects which use this approach, including Tcl/Tk.
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On 1/15/18, Dan Wilcox danomatika@gmail.com wrote:
In thinking again about Pd's build system(s) while working on the Windows build, I think there is a good solution which would allow combining both the Makefiles and autoconf.
As far as I see it, the pros/cons of the various systems we have now are:
- makefiles: easy to understand & fast, less adaptable / configurable
- autotools: easy to use and configurable, harder to understand, lots of
files
I think we definitely want to pros of both: easy to understand, easy to use, configurable.
Since the autotools (autoconf. automake, etc) are built around make already, it's not like these systems are mutually exclusive. The Makefile.am automaker files are used to generate Makefile.in files which are used to generate the Makefiles.
I propose that we transition from using automake directly and write our own Makefile.ins. This way more of the actually logic is shifted to the Makefile.in files themselves while we still get the configuration variables from the configure script. The con for this is we lose a lot of the boilerplate stuff that automaker handles but would gain Makefiles which basically look like Miller's original makefiles.
Additionally, the cross platform stuff like file lists and install rules, etc could be defined in a shared Makefile and we keep the platform specific makefiles. Last, we would be able to handle custom rules & approaches by not having to fight automake for things like generating binaries in the bin folder and making a "sourceful" release build in place with ./configure.
There are a number of projects which use this approach, including Tcl/Tk.
Sounds like a good idea, to consider at least. You've proposed it before, sorry for not responding earlier. What I appreciate most about handwritten makefiles (when compared to full autotools route):
1. control over stdout and stderr text 2. control over targets and rules
Makefile readability is not the main issue in my view. A makefile.am is easier to read and write than a handwritten multiplatform makefile for the same project.
I don't know much about autotools, but I've always thought that you can't define your own (additional) targets in a makefile.am. For troubleshooting during development but also thereafter, I find it indispensable to have targets that print variables, dependencies, intermediate output (preprocessor and assembly) and such. Vanilla's handwritten makefiles don't have such targets but they could easily be added and that would be an asset for everyone trying to help developing and bug fixing. If it is possible to combine the undeniable advantages of configure with handwritten makefile.ins, that could be the best of both worlds.
Katja
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Jan 15, 2018, at 11:21 PM, katja katjavetter@gmail.com wrote:
I don't know much about autotools, but I've always thought that you can't define your own (additional) targets in a makefile.am.
You definitely can. You can define your own targets, as we have done with some of the Makefiles in Pd ala "make app": https://github.com/pure-data/pure-data/blob/master/mac/Makefile.am#L19 https://github.com/pure-data/pure-data/blob/master/mac/Makefile.am#L19
You can't really override the default targets but you can extend them with *-local and/or *-hook : https://www.gnu.org/software/automake/manual/html_node/Extending.html https://www.gnu.org/software/automake/manual/html_node/Extending.html
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On 1/15/18, Dan Wilcox danomatika@gmail.com wrote:
On Jan 15, 2018, at 11:21 PM, katja katjavetter@gmail.com wrote:
I don't know much about autotools, but I've always thought that you can't define your own (additional) targets in a makefile.am.
You definitely can. You can define your own targets, as we have done with some of the Makefiles in Pd ala "make app": https://github.com/pure-data/pure-data/blob/master/mac/Makefile.am#L19 https://github.com/pure-data/pure-data/blob/master/mac/Makefile.am#L19
You can't really override the default targets but you can extend them with *-local and/or *-hook : https://www.gnu.org/software/automake/manual/html_node/Extending.html https://www.gnu.org/software/automake/manual/html_node/Extending.html
That's interesting, didn't know that. Still I guess you have more flexibility with plain make since you control all variables being used in a rule.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Jan 15, 2018, at 11:21 PM, katja katjavetter@gmail.com wrote:
I find it indispensable to have targets that print variables, dependencies, intermediate output (preprocessor and assembly) and such.
For this, you can use the verbose make option "make V=1" or "make VERBOSE=1" and/or a dry run "make -n" https://stackoverflow.com/questions/5820303/how-do-i-force-make-gcc-to-show-... https://stackoverflow.com/questions/5820303/how-do-i-force-make-gcc-to-show-me-the-commands
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On 1/15/18, Dan Wilcox danomatika@gmail.com wrote:
On Jan 15, 2018, at 11:21 PM, katja katjavetter@gmail.com wrote:
I find it indispensable to have targets that print variables, dependencies, intermediate output (preprocessor and assembly) and such.
For this, you can use the verbose make option "make V=1" or "make VERBOSE=1" and/or a dry run "make -n" https://stackoverflow.com/questions/5820303/how-do-i-force-make-gcc-to-show-... https://stackoverflow.com/questions/5820303/how-do-i-force-make-gcc-to-show-me-the-commands
What I mean is targets that give you specific info (but not doing the build). Like printing a list of all makefile variables with their values, or a list of paths, or dependencies (so you need not search through thousands lines of build log). Or print / save preprocessor / assembly output for a specific C file. Such targets are easy to set up if you have full control over variable definitions. Pdlibbuilder has such 'convenience' targets and they're helpful not only during C development but also when people report issues.
But this doesn't touch upon your central question of unifying Miller's makefile approach with the autotools, it would be an extra feature rather.
Katja
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On 2018-01-15 23:21, katja wrote:
Sounds like a good idea, to consider at least. You've proposed it before, sorry for not responding earlier. What I appreciate most about handwritten makefiles (when compared to full autotools route):
- control over stdout and stderr text
could you elaborate on that?
- control over targets and rules
Makefile readability is not the main issue in my view. A makefile.am is easier to read and write than a handwritten multiplatform makefile for the same project.
+2
fgasm,dr IOhannes
-
Dan Wilcox -
IOhannes m zmoelnig -
katja