Erick, I'm having a hard time reorganising the library due to the way the file copying is done: I don't understand how your caching stuff works. I want to do things like put flx_stream into lib/std/io, instead of the lib, where it makes the library look really messy.
The "copy_flxs_to_libstd" routines etc are a pain, because they're in buildsystem/__init__.py or something but called from fbuildroot.by. I need to be able to pick some files and target locations for them. Ultimately, the build is a bit of a mess because we have: a) the source directory b) the build directory and the organisation of the build directory is different, and at the moment changes to the source directory don't cause the build directory to be updated (eg editing a flx file) even when using your caching stuff: it would probably be easier to just copy everything every time, although that would make the *.par files out of date and force a rebuild. Also (c) the install directory isn't a copy of the build directory because that contains some temporary files. Normal build systems (make etc) just make everything in the src directory, selectively install files, and provide a cleanup. This sucks.. but what fbuild is doing sucks too. Part of the problem is that things like faio, demux, contain Felix and C++ in one "package" but the target directory splits flx and hpp up, and drops the cpp files, but adds built libraries (leaving out built *.o files). Felix was actually design so that *.flx files lived next to *.hpp files, the idea being you could go into say /usr/include and add the Felix bindings for libraries. But that makes the directories look messy. OTOH splitting things up by file type instead of function is unsustainable: see Debian, which makes a right mess of it. Works for system libraries, but once user libraries (eg Python) come into play, everything goes into /usr/lib/python so commands like "rm" will find everything in one go (and so can the user). The real answer is virtual directories.. so you can have your cake and eat it too. Sun uses 'opt' for packages, but the downside is now your PATH is massively long and hard to maintain, just to find executables. -- john skaller skal...@users.sourceforge.net ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
