[Ecls-list] Adding Libraries....

Juan Jose Garcia-Ripoll juanjose.garciaripoll at googlemail.com
Fri Nov 13 07:07:53 UTC 2009


2009/11/12 Marko Kocić <marko.kocic at gmail.com>:
> How is it different to cl-opengl? What was rationale for this?
> Anyways, I doubt it will be included to ECL, since it is not core
> functionality, so separate project(s) would be interesting?

It depends on whether the bindings are ECL specific using c-inline and
other extensions, or just UFFI based (which would be portable), or
ports of existing bindings to ECL. And of course it also matters the
size of it all. If it is overall a few hundreds of k I would not mind
including it, but if over time it grows significantly (> 2Mb or so)
and not all users are going to profit, then one should consider a
separate source tree.

Another perhaps more reasonable possibility would be to set up a
subproject in sourceforge, organizing the optional libraries
consistently

ecl-contrib/gl/opengl
ecl-contrib/gl/glu
ecl-contrib/gl/sdl
ecl-contrib/gl/cairo
ecl-contrib/gnome/...
ecl-contrib/gnome/pango
...

>From the point of view of GIT, I have read arguments favoring one
source tree per project, specially if the whole thing becomes very
large, but that might become a maintainance mess.

OTOH if you decide it is more convenient to set up a separate tree,
notice that ecl-readline has its own project site at common-lisp.net
They ask very little for hosting projects and provide
CVS/svn/git/darcs infrastructure. ECL could then still support
automated installation via wget / curl at configuration time.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com




More information about the ecl-devel mailing list