I have been improving the separate compilation mechanism, but for now
I want to look at the tooling.
At present, the _interface.flx file goes in the text cache, alongside the *.hpp
file
it requires. For some reason the object files also go in the text cache, however
libraries go in the binary cache.
The names of these files are quite consistent and universal:
$HOME/.felix/text/`pwd`/*base*
and replace text with binary. But what do we want?
I will look first at the highest level because it's easier. The lower levels
of management are actually harder.
Suppose we have a file
mylib.flx
which of course might include other files. What we want to produce with this is
the
same as how we would manage either
(a) a Felix core package
(b) an external package
Installed Felix core packages follow rigid rules. The interface Felix code goes
in
$INSTALL_DIR/share/lib/*
where * may include some subdirectory structure, such as std/datatype/ ....
The required C++ headers and binaries go in
$INSTALL_DIR/host/lib/rtl
The config file goes in
$INSTALL_DIR/config
Note that with a package file, we no longer need to put a #include in the
interface,
and we no longer need to link the library on the command line, the interface
can just
say
requires package "mylib";
This will find an installed package. So, one way to organise the compilation is
to
output everything into a given base "in the image" of the install for example:
flx --package=mylib mylib.flx
would produce (on OSX):
mylib/share/src/mylib.flx # copy
mylib/share/lib/rtl/mylib.hpp
mylib/share/lib/mylib_interface.flx
mylib/host/lib/rtl/mylib.dylib # .so on Linux
mylib/host/config/mylib.fpc
to be complete, we should make the static versions of this too. Note that
non-product temporary
files might go in the cache still. Clearly we can install by just
sudo cp -r mylib/* $INSTALL_DIR
and then everything will just work "as an extension" to Felix. Of course,
everything is lost
if we upgrade Felix. So we need a consistent way to rebuild. And to build for
multiple
targets.
For non-core packages, we need a persistent place to put them for development.
The assumption is these things are not Felix version dependent, so normally
we just have to rebuild with new versions of Felix: sometimes we have to upgrade
the source for the latest Felix. Contrarily these packages would have their own
versioning.
We also need a place to install these things that doesn't get clobbered by a
Felix install.
For example
/usr/local/lib/felix/user-packages
Although it's tricky to get right, we might "autobuild" things with upgrades.
By far the biggest problem here is that the install point is normally owned
by a sysadmin such as root, so we have to separate building from installing.
So for many packages we need two paths: to the build directory first then
to the install directory as a fallback (otherwise we can't test our programs).
There's another way to do this: just put everything in
mylib
without any structure, and make the install program do the hard work.
I note that the *.fpc file may need modification!
This packaging concept is "overkill" for simple things. For example
you have
program.flx
and you want to split out part of the code into
mylib.flx
With caveats about order of initialisation of global variables this is easy
enough,
and you can just include mylib in program. But soon this gets slow, so you want
to
separately compile mylib.
There's actually an argument that you should use
mylib.fdoc
and the interface should just be
mylib.flx
This means your original program which says:
include "mylib";
and worked by including mylib.fdoc will transparently switch
to including mylib.flx once mylib.fdoc has been compiled.
[this won't quite work because of "export" but it's an interesting idea!]
So actually .. getting the export semantics to work is much less of a problem
than tooling, i.e. just deciding where to put all the files!
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
