I am trying to figure out the overall mechanism to build a "felix install".
This is a particular configuration of sources, tools, libraries, etc,
for a particular purpose. The "usual" one is everyday host compilation
by a single user.
The current system is to run fbuild which guesses at the toolchain
and configuration, builds stuff in build/release, and then we call
install to copy stuff to /usr/local/lib/felix/felix-version plus some
executables and libraries go in /usr/local/bin and /usr/local/lib.
In the process $HOME/.felix is created and hold the cache,
litterbox, and, if you rebuild or play about, you can add extra
or overridding *.fpc config files which affect the next build.
I now have a new program which can (just) compile and link
the core RTL (run time library). It works like this:
flx --test=build/release src/tools/flx_build_rtl_demo.flx build/release/config
felix_build trial repo
in the abstract the arguments are:
config_directory
bootstrap_config_record
output_directory
repository_directory
I'm using config_directory=build/release to test the program. However the whole
thing is a bit unsatisfactory.
At the moment, the config directory must contain OS specific toolchain
specific switches, for example we have fields like:
provides_dlib: -lflx_async_dynamic
This says, when you're linking a dynamic library that depends on flx_async,
throw in the switch -flx_async. It's clearly only going to work with a
particular
linker on a particular platform. Of course the whole idea of the config system
is precisely to isolate such platform variant information in one place.
However, this switch doesn't tell the builder what library to build,
on OSX that's
libflx_async_dynamic.dylib
The builder itself is generic so it cannot parse such switches:
the toolchain could, but we're making assumptions you don't
have something like:
provides_dlib: -lflx_async_dynamic weird/support.dylib
which is also a valid input to a linker (a full path name of a library
can be given as well as the unix shortform).
Similarly headers are specified by:
includes: '"flx_executil.hpp"'
This tells Felix to write
#include "flx_executil.hpp"
in your C++ program when you say
requires package "flx_executil";
but it doesn't help the build tool decide which headers
to put in the build image (I copy all of them including
private ones which is plain wrong). It also doesn't say
where to find the headers in the source. The tool just throws in
some -Idir switches.
===============================
So we have some issues here:
1. To make a configuration, we have to duplicate a lot of
information, possibly with toolchain variations on some
fields, so we have config packages for windows, linux,
unix, windows, etc. This is because fbuild simply copies
packages from subdirectories of config into the top level.
Then we throw user add-on configs over the top, in case
the user needs to modify something for their platform,
or add new stuff without changing the repository.
Trivially, unix and osx both use -L -l -I switches for libraries,
on both clang and gcc.
To make this work in general you'd need a copy of the whole
configuration for every platform/toolchain/user combination.
2. The same "abstract" information is repeated in different ways
to satisfy the requirement that fields need to be platform dependent.
I really want to say:
library: fred
headers: src/fred/public/.*\.hpp
build-header-dirs: src/fred/public/ src/fred/private
srcdir: src/fred
compile: .*.cc
compile-dynamic: .*\.dcc
compile-static: .*\.scc
link-dlib: ,,,
etc etc. This is a complete specification of where everything is, and how to
make
the libraries, all in the abstract. Then in case weird overrides are needed,
the user can throw in custom overrides.
The spec above should actually live in the source, however we then still need
some
central way to find the source packages.
================
To understand some of the issues, consider demux.
It provides socket and timer event polling using select,
poll, epoll, kqueue, win32event ports, solaris event ports, etc.
Choosing which of these things to build and use is current done
in the Python script based on availability of headers. But that's a guess.
We actually need to provide "abstract build instructions" for each subsystem,
and let the user choose which ones to build and use (you can build
select, poll, and epoll on linux .. I don't even know how it choses to actually
use epoll).
Similarly, Judy requires a MACRO switch to determine if it's being
built 32 or 64 bit.
================
The bottom line is basically: how do we specify the configuration??
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
