I think these enhancements are definitely useful and good, but some belong elsewhere. The key focus of this template is to be as simple as possible and represent only the most common types of libraries. Then it provides an easy place to get started. It is not meant to work for every kind of library. For that, we should have an autotools template.

Also, this library template is for future libraries, not existing libraries. The template can be customized for existing libraries, but doesn't need to support all of them out of box.

On Aug 21, 2010, at 3:57 PM, IOhannes zmölnig wrote:

i cleaned up the template Makefile (externals/template/Makefile) a bit.

namely i switched to using $@, $< and $^, which makes a lot of things way more elegant.

This stuff is more elegant to a make programmer but not to everyone else. The old code is more readable to people who don't know more than basic make. It was working fine as it was. I can never remember what the difference is between $@, $< and $^, but I can easily remember the difference between $*.o, $*.c, and $*.$(EXTENSION). So yes, I deliberately avoided using extended make features to keep the Makefile more readable to people who don't know make. Therefore, I reverted these changes.

other cleanups: removed the SOURCES_android since this is not used anywhere and is misleading

ok.

use PD_PATH where appropriate

ok

added SOURCES_LIB for .c files holding shared functions

This belongs in the full-featured autoconf template, not in this simple template. There are already too many different variables to set in the header as it is. People who want to build everything in a single file using this template can use the single shared file (i.e. template.c). Therefore I reverted these changes.

use HELPPATCHES to enumerate -help.pd (usually this info is gathered automatically; the average user will never see that)

ok

these changes should make zero difference to the user experience of the templ Makefile.

remaining questions: DIST PATH: why does the makefile enforce the manual and examples to be examples/ resp. manual/ folders _in the source directory_ ? i understand that they should be laid out standardized in the install directory, but why in the source folder? why not just: MANUAL = doc/manual.pdf manuals/anothermanual.pd and install that into .../$(LIBRARY_NAME)/manual/

There are many reasons to do this, here are some: - standardized folder names make it easy to document - standardized folder names make it easy for people to understand other libs - keep things simple as possible

Again, this is a template for new libraries, not every library. People who want to customize can customize to their heart's content.

INSTALL PATH why the heck is the default installation path: $(libdir)/pd- externals ??

i cannot remember that this was agreed on by anybody but hans. i do remember that ~/pd-externals was discussed (and i still would prefer ~/.pd/extra/ over this unnecessary homedirectory cluttering), but $(libdir)/pd-externals is news to me.

instead i do remember, that $(libdir)/pd/extra was meant to be the canonical name for all flavours of Pd (e.g. with PdX and pd-vanilla, in debian pd-vanilla would look into both /usr/lib/puredata/extra and /usr/lib/pd/extra, whereas PdX would look into /usr/lib/pd-extended/extra and /usr/lib/pd/extra (in this order))

i also find, that a related patch has made it into puredata.git. unfortunately, it is inconsinstent with the template Makefile, as puredata.git has hardcoded /usr/local/lib/pd-externals/ whereas the tmpl uses $(libdir)/pd-externals which could well be /usr/lib/pd-externals/ which in turn is never ever searched by Pd.

in case, i haven't said it yet: i don't like this.

"pd-externals" is the name of the folder for user-installed externals on UNIX. There is both a user folder (~/pd-externals) and a system- wide folder (/usr/local/lib/pd-externals). The system wide folder should not be /usr/local/lib/pd/extra because that could easily be the install location of another copy of Pd. Having "make install" put files into your home directory seems wrong to me. Therefore, /usr/ local/lib/pd-externals is the default.

Indeed, /usr/lib/pd-externals does not make sense. AFAIK, no GNU/ Linux distro recommends people installing straight into /usr/lib, so people who are doing "make prefix=/usr install" are already doing something against standard practice. They should therefore have not be surprised that it would work properly.

For packaging, you can do "make pkglibdir=/usr/lib/pd/extra" like in the Debian files. I suppose this could be cleaner in theory, but in practice, trying to make these variables fit all the possibilities of UNIX, Mac OS X and Windows is quite difficult.

.hc

----------------------------------------------------------------------------

I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler