[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