On Thu, 2006-08-31 at 15:24 -0400, Peter Tanski wrote:
> On Aug 31, 2006, at 2:01 AM, skaller wrote:
[Search paths]
> Why not add these things as ./configure flags?
Why not? :)
You might want:
--with-paths=pathfile.paths
i.e. to make a file with all the directories to search, and just
name the file. This would be more 'persistent' than having
to type the name of the directories every time you run configure.
On Unix you could even default to
/etc/felix/pathfile.paths
if it exists. The Felix compiler flxg already searches -I directories,
so using paths is logical .. the problem is really:
"Arggg .. there are so many ways to do this, which
one do we pick?"
> > Basically the key problem is how to have something
> > which is
> >
> > (a) persistent -- Felix doesn't clobber it
>
> Set a default in the configure to use whatever is available--you used
> to have that when you kept config.py if it existed.
Yes, but I change that, because the implementation relied
on 'execfile' which is fine for a couple of lines ..
but as you yourself say, isn't a very robust way of doing
things.
With hundreds of configuration parameters of unbounded
number due to extensibility, and with frequent changes
to the build system .. this made developers life a nightmare.
In principle, if the config was stable this wouldn't affect
end users .. but the config has not only changed by extending
fields with successive releases .. the structure has changed
each time too.
And it is tricky to 'parameterise' things like 'compiler',
which is not a set of fields but actually a full scale
complex Python class (gxx, msvcxx etc)
I am almost tempted to do it with an SQLlight database,
the main problem being bootstrapping.
I am also tempted to build a GUI front end to the
configuration .. but the same problem: bootstrapping.
[And Tk doesn't have a tree widget which is bad,
you have to use Tix which is an extension ......]
> > (c) modifyable -- the user can change it
>
> Put flx_config.fpc in the user's home directory, under .felix (on
> Posix); in the registry on Windows.
Can't: Debian autobuilder etc. Some Unix users will be ordinary,
some will be group admins, some will be the sys admins, and
some will be the actual system, some will even be networked.
What you suggest makes sense IF there were also a parameterised
modular extensible install system, so we could distinguish
installation classes and build models for them.
> > (e) changeable -- new versions use different layouts
>
> This requirement seems to kill all the others,
Yeah. That's the problem.
> particularly (a),
> since it implies the configuration system *must* clobber any
> persistent header.
Well, the way to think about this is by analogy.
Software engineering faces this problem all the time.
The requirement is the Open/Closed principle.
Programs usually change representations with conversion
functions -- you just stamp the config with a version number,
detect it, and convert if an old format is found.
In theory .. it's not that hard. But this is a LOT of
work for a system without a stable user base.
We've already put too much work into packaging and
the build system, IMHO, compared to actually writing
libraries.
> The balance seems to be the Felix-system
> developer's ability to define new build settings and the user's
> ability to keep them. While backward-compatibility may a hassle, why
> not just define a standard and stick with it as long as possible?
Well, the cpkgs stuff tries to do that, by making the configuration
of add-ons systematic and modular, it leaves the core config
unpolluted and more likely to stabilise.
but more refactoring is needed. For example probably we
need two more directories:
fpcs -- contains the *.fpc files, instead of config.
ufpcs -- persistent, non-generated fpc files,
probably get copied into 'fpcs' if found
Of course if the *.fpc layout changes, the ufpcs will have
to be upgraded by hand.
Typically, I let clutter accumulate until I see a pattern
to stimulate refactoring: redesign is easier than design,
and comes with test cases for free :)
To me, this is probably a 'better' solution than search paths.
It's easier to implement, fully portable, and complete:
but it doesn't exclude the search paths (which only get
used for non-persistent *.fpc creation).
What's more, you can always create the ufpc directory
initially by copying the generated one. The main trick
here is to force a reconfig, in case the generated one
failed: there's no way to re-run configs at the moment,
once they fail, you have to rebuild the whole system.
[Aside from cheating by deleting the relevant files .. ]
> The key to portability is standardisation:
100000% agree :)
But standardisation works best if backed by at least some
'existing practice'.
> What you seem to be developing
> here is your own Felix distribution system.
Indeed. Since Felix is source code based, eventually I'd like:
--------------
import MyModule;
...
and Felix goes off and looks on the Internet, downloads
the source file, verifies it, checks the security rating
of the vendor site meets automatic download requirements
of the user, and then just goes on compiling.
Java is close to this: modules are named after the vendor
web site:
com.sun.java.awt.mywidget
which is very nice in many ways, since it tells you where
the code came from, and hence where to look for documentation
and updates.
> > var path=getenv("PKG_CONFIG_PATH");
>
> Don't rely on an environment variable.
> (1) it pollutes the user's environment with yet another variable
> (2) users who don't read directions first and simply type ./configure
> may miss it
Agree. However env-variables are the windows way, short of
using the registry (I have no idea how to do that using
say Python script).
> > I'm not sure the current build system can handle that.
> > At present there are phases of building .. but the phases
> > are based on requirements of cross compilation.
>
> What can you separate out?
The way it works is to build these stages in sequence:
build, host, target, run
for all the detected packages, in an order determined
by a topological sort of 'requires' specifications
within the modules themselves.
The ordering is the same for all phases.
The compiler flxg is a host tool, so it is built in the
host phase.
Elkhound parser generator is a host tool, so it too is built
in the host phase.
The Elkhound parser run time is a target engine, so it is
built in the target phase.
Both the parser and run time engine of Elkhound use a common
library.. so the library is actually built twice. This is
necessary because you may be writing Felix code under Cygwin,
using Cygwin version of Elkhound to generate C++, but you
compile with MSVC++, and so need an MSVC++ dll for the run
time engine.
At present ALL the unit tests are bugged, because they cheat
and run in the target phase instead of the run phase.
In theory, the tests should all be built in the target phase,
but only executed in the run phase. In particular if you use
MinGW under Linux to build Windows binaries .. clearly you can't
actually run them under Linux (but the test system will actually
try :)
I hope that explains what the 'phasing' is for. Most packages
are designed for a single phase. The build system can be TOLD
to only do a particular phase, for example
./umk --phase=host
will build the Felix compiler and Elkhound, but not compile
any of the run time libraries.
Again, this is mandatory on XP64 trying to build 64 bit
Win64 code, because tools like Ocaml and Elkhound can still be
32 bit if the host system is Win32 and the target is Win64.
In fact, the target can be win32, and the run system win64,
using a 32 bit hosted 64 bit code generating cross compiler
which MS supplies. It's a bit messy, since 'target=win32'
seems to imply targetting 32 bit code, but this isn't the
case, and the build system (and me) gets confused here
about whether the phase names its environment, or the
environment its products will use.
> Is this problem due to OCaml?
No. Ocaml is only needed in 'host' phase to build the compiler
which is a single statically linked executable. (Unless
you're stuck with bytecode .. :)
If Ocaml supported Ocaml dynamic loading with native code
Felix might not exist at all -- I'd be using Ocaml and telling
everyone else to as well.
> think that is another key problem. There should be separate
> configuration phases (taking precondition parameters from the
> master ./config, of course) for each third-party application.
Well, running ./configure is another phase, not handled
by the build system.
However add-on modules like GMP don't use this, they
configure 'on the fly' during the execution of the build
system. This JIT based configuration is a bit of a hack:
there is no separate phase for it, instead the configs
are done at the last minute but just in time: satisfying
the required dependency.
An important point is that the JIT configuration script
has access to the core configuration. So, for example,
it knows whether it is running on Windows or Linux or OSX
and can generate stuff accordingly .. BEFORE the script
is executed .. however the staging is fragile.
Interscript extracts on add on packages fail if the
core configuration hasn't been run, because almost all
the *.pak files 'execfile' the core configuration to load
the parameters into the Python global namespace.
> > Yes. Worse, you can't even compile installed examples,
> > because the compiler(s) don't allow 'shadow' writable directories.
>
> Is that why you have to use 'make virgin' every time you want to
> rebuild?
No, make virgin is for when the dependency checking fails,
or things otherwise screw up: starting from a virginal
condition, without rerunning the config script, ensures
a clean build.
For example sometimes I remove a test from the system,
but re-extracting the test suite doesn't delete the old
test, there is no 'uninstall' for anything, and the
tests are located by globing. So the old test hangs
around until deleted.
> Why is that? Can't the system follow symbolic links?
Sure, but Windows doesn't have symbolic links.
And you really don't want to symlink all 150+ test
examples do you? Symlinking the directory of
course doesn't help.
--
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
