[PD-dev] Re: [PD] building HID from the CVS, errors
Thomas Grill
gr at grrrr.org
Wed Aug 9 12:37:43 CEST 2006
Hi all,
agreed. Personally, I rarely use the extended distro since i only need a
few externals or library, and i don't like to be dependent on a large
and probably hard to maintain build system.
I advocate simple Makefile files that are self-consistent and
Makefile.extended or whatever for Hans' GUBS.
greetings,
Thomas
IOhannes m zmoelnig schrieb:
> David Merrill wrote:
>> Hello all,
>
> hi.
> i am redirecting this to pd-dev, since i hope this mail will lead to
> some further dev-specific discussion and hopefully to some usable
> build system.
>
>>
>> Has anyone else had a problem trying to compile an external from the
>> CVS source? I just checked out the externals dir from CVS, and wanted
>> to compile the latest [hid], so after reading the README in the hid
>> directory, I typed:
>>
>> >make INCLUDE=/usr/lib/pd/src PDEXECUTABLE=/usr/bin/pd
>>
>> ..and got the following:
>>
>> --paste--
> [...]
>> --end paste--
>>
>> Why would the build want a /sigpack, and /zexy directory? And am I
>> missing a Makefile.buildlayout file?
>
> to compile hid (and i guess, any of hans's externals) you need the
> entire pd-cvs (at the very least you need the "packages" module)
> downloaded from sourceforge.
> i agree that this is _very annoying_ at the least.
>
> my solution to compile something as simple as [folder_list] was to NOT
> use hcs's build system at all (i really just wanted to have to
> download not more than 1MB to get this single object), but instead
> compile the object with:
> > gcc -g -O2 -I. -DPD -fPIC -export_dynamic -shared -o folder_list.o
> -c folder_list.c
> > gcc -export_dynamic -shared -o folder_list.pd_linux folder_list.o
> -lm -lc
>
> you might try something similar with hid, although things are a bit
> more complicated here.
>
> that's basically the answer to your question, the rest is what i draw
> as a conclusion:
>
> SO:
>
> i see the need for a "grand unified build system" for things like
> pd-extended. but i am not totally sure, whether everything should be
> sacrificed to pd-extended.
> naturally, hans has the right to do anything with his code, including
> forcing anyone trying to build the sources from his part of the
> repository with any build system he likes.
> nevertheless, i would recommend a system that would make the best of
> the two worlds: be able to take advantage of the general pd-extended
> build system and (at the users option) be able to not have to use the
> pd-extended build system (probably at the cost of having to do some
> manual configuration if the maintainer doesn't want to maintain to
> configuration systems)
>
> the simplest solution that comes to my mind is, that one of the 2
> systems uses a differently named makefile.
> since pd-extended's build-system is more likely to be called from a
> parent makefile (because somebody wants to build the entire
> pd-extended build-system), i suggest to name this Makefile.extended
> (or Makefile.buildsystem)
> anybody wishing to build using the extended build system, would call
> "make -f Makefile.extended".
> other users would just do a "make".
>
> a more sophisticated method would use a Makefile.extended and a
> Makefile.simple.
> the ordinary "Makefile" would first check for the existence of the
> extended build-system and if present, it would use Makefile.extended,
> else it would use Makefile.simple.
>
> if test -e ../../packages/Makefile.buildlayout
> then
> # cool, we can use the extended build system
> make -f Makefile.extended
> else
> # simple fallback
> make -f Makefile.simple
> fi
>
> what do you think?
>
>
> mfg.adsr
> IOhannes
>
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
>
>
--
Thomas Grill
http://grrrr.org
More information about the Pd-dev
mailing list