[PD] installing netpd under gentoo using layman error maxlib

[Hans-Christoph Steiner]

The Pd-extended Makefiles do use DESTDIR, CFLAGS, etc. but are only  
somewhat hierarchical.  That stuff could be greatly improved for  
sure.  Patches welcome :D

I think that it autoconf/config.h should be the technique for  
handling libs and other dependencies.  Perhaps automake would be  
useful in the long run, Bryan Jurish outlined how to use it with Pd  
on this list a little while ago.

.hc


On Nov 20, 2007, at 11:34 AM, errordeveloper at gmail.com wrote:

> On Tue, Nov 20, 2007 at 04:59:18PM +0100, mescalinum at gmail.com wrote:
>>
>> heh, it would be a definitely GOOD THING to tidy up our build  
>> systems.
>>
>> but HOW?
>>
> i think of having one Makeglobal which will contain DESTDIR, CFALGS ,
> *FLAGS ..etc all the general variebles.. and procedures (or how do you
> call it in make terminology ?) - ah targets may be ..
> i mean the way you wanna do make install and make clean .. etc
> i'd suggect make syminst (which will link .pd and .pd_linux) files  
> into
> the path instead of copying it - save a litle space (practicaly) AND
> make update of the abstraction very simple!
> so there we set like all the abstractions to go into $libdir/abs or
> something that you perefere ..
> and the externals can go into $libdir/ext - stick to 3char  
> convention is
> a good idea i think (once the situation permits)!
> so i'm just giving some organizational idea ..(i organize my
> installation in that manner actually).
>
> so having this Makeglobal (or ..Makefile.glob if you wish),
> athors just add their Makelocal's which will only contain the
> compilation procedure definition.
>> one solution could be modularizing and hierarchicalizing  
>> Makefiles....
>> perhaps pd-extended build system uses this approach (Hans, can you
>> spend some words here?).
>>
>> another approach could be auto*-tools, but I don't know anything  
>> about that.
>> if anyone has experience with that and he thinks it is reasonable to
>> use autoconf/automake.... it would be appreciated if he can write  
>> some
>> lines on the wiki, describing a standardized build procedure for
>> externals based on autotools
>
> i think we don't really need autoconf or any of those -
>
> having the above structure one can just go into the external's dir and
> do make install or make syminst
>
> we don't need --with-blah and --enable-foo for simple externals , i  
> reckon
>
> apart from massive things like GridFlow and GEM ..(which have  
> already got it ;)
>>
>> writing Makefiles it means much more than making a bunch of C  
>> files to compile.
>>
>> the end user just use the compile part, but other environments (see
>> the Gentoo build system) use more advanced Makefiles features.
>>
>> I just mention some:
>> - CC, STRIP, LD, ...  variables can override the default programs
>> - DESTDIR is used as filesystem root for staged installs
>> - test target is used to perform tests
>> - CFLAGS, CXXFLAGS *must* be honored instead of hardcoding CFLAGS
>> (like -march, -mcpu, -funroll-loops, -fomit-frame-pointer, -fpipe,
>> ...) into Makefiles
>>
>> I wrote very few externs (notemono, tracker) and I should admit even
>> my makefiles are broken and don't respect all of the above features
>>
>> writing a Makefile by hand is a PITA and much error-prone :|
> i don't think it's a big deal to have some basic makefile structure  
> like that ..
>
> ok, well if we got any auto-tools specialist , who has a good solution
> now around here ..
>>
>> just my 0.02 Euro
>> -- 
>> Federico Ferri
>
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list



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

                   ¡El pueblo unido jamás será vencido!