On Thu, 2006-08-31 at 01:03 -0700, Erick Tryzelaar wrote:
> skaller wrote:
> > >From the source code:
> >
> > var path=getenv("PKG_CONFIG_PATH");
> >
> > Doesn't help much .. flx_pkgconfig isn't built yet :)
> >
> > Maybe the thing to do is separate Felix *core* from
> > third party tools, to ensure it IS built by the time
> > deviant packages are installed.
> >
>
> I'm planning on doing this. Maybe this, or next weekend if I got some
> free time. My idea is that we factor the build system out of the core.
> Then, we can use it to drive both the core build, and all of the third
> party/non-required libraries.
This will be tricky -- take care! The 'build system' isn't just
plugins and code, it's also a protocol than various .pak files
implement.
Note also that Felix is tied to flx_pkgconfig both inside
the build system, as well as the 'flx' script.
Finally .. the really hard bit. If one installs the built
core, then tries to build and install addons .. how can
that work with the installed Felix? At present all the
add-ons have to built in the development directory.
At least the installation directory may (a) not contain
all the data and (b) not support writing.
At least for flxg itself this is a fault in the compiler:
it writes *.par and .[ch]pp files next to the source, and there is
no provision for writing anywhere else. This needs to be fixed.
Similarly the bash script flx needs to be able to support
'shadowed' directories: a write directory with a read only
source directory behind it.
Anyhow the difficulty of separating the core and add on builds
out is the current need to have everything in a development tree
prior to installation. To add in more, the development tree
needs to be retained.
Also in Debian, the documentation is installed monolithically,
possibly NOT in the install root, but perhaps in
/usr/share/doc/felix.
At least the 'index' page is monolithic .. it has to be coded
to link to every document, and can't be easily extended with
extra plugin things. Of course the Debian package manager
itself can cope with separate installation by way of
separate packages.
IMHO, if we're refactoring the system to split out 'packages'
we should keep an eye on how this ought to be reflected in
Debian: the existing tarball and build could 'easily' be
turned into half a dozen Debian packages right now.
That's a different problem from actually building them
independently ;(
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Felix-language mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/felix-language
