[PD-dev] template Makefile

Hans-Christoph Steiner hans at at.or.at
Mon Aug 23 18:49:51 CEST 2010


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





More information about the Pd-dev mailing list