Considering that its now building nightly automatically on numerous
platforms, and I've largely single-handedly converted most of the
libraries in CVS to build in libdir format, I don't think the Pd-
extended build system has proven hard to maintain. I do sleep, and
actually have a life outside of the Pd-extended build system...
sometimes... ;)
In fact, its much better than anything that existed before. That is
not to say there isn't a lot that could be improved. config.h!!
.hc
On Aug 9, 2006, at 6:37 AM, Thomas Grill wrote:
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
[email protected]
http://lists.puredata.info/listinfo/pd-dev
--
Thomas Grill
http://grrrr.org
_______________________________________________
PD-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/pd-dev
_______________________________________________
PD-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/pd-dev
