I've finished reworking the build scripts. Before this rework, the build was managed by a bunch of Ruby scripts which first used javac to compile jfan, then the jfan compiler was used to build all the pods. Now we use Fan build scripts and the Fan version of the Fan compiler.
In order to bootstrap the build you must have a "released Fan" installed, by convention located at "/dev/rel". The rel installation is used to run the top level build scripts and to build the core subsystems (the Java/.NET runtimes and the sys, compiler, and build pods themselves). Then once the development environment is bootstrapped, we use the development environment itself to build the rest of the pods.
The secret sauce in this design is a hack in the Fan launcher which allows us to map specific scripts to use an alternate Fan runtime using "fan.runtime.substitutes" in sys.props. The default sys.props maps all the boot build scripts to the /dev/rel runtime - this lets you set your path to the development runtime's bin and not have to worry about which version of "fan.exe" is invoked.
We break up a full build into three scripts:
buildall.fan (uses rel runtime) - routes to buildboot and buildpods
buildpod.fan (uses dev runtime) - builds rest of pod library
Eventually buildall will manage all the other top level things like building the distributables. For now I'll just manually create a zip as the distributable.
brian Mon 1 Jan 2007
I've finished reworking the build scripts. Before this rework, the build was managed by a bunch of Ruby scripts which first used javac to compile jfan, then the jfan compiler was used to build all the pods. Now we use Fan build scripts and the Fan version of the Fan compiler.
In order to bootstrap the build you must have a "released Fan" installed, by convention located at "/dev/rel". The rel installation is used to run the top level build scripts and to build the core subsystems (the Java/.NET runtimes and the sys, compiler, and build pods themselves). Then once the development environment is bootstrapped, we use the development environment itself to build the rest of the pods.
The secret sauce in this design is a hack in the Fan launcher which allows us to map specific scripts to use an alternate Fan runtime using "fan.runtime.substitutes" in sys.props. The default sys.props maps all the boot build scripts to the /dev/rel runtime - this lets you set your path to the development runtime's bin and not have to worry about which version of "fan.exe" is invoked.
We break up a full build into three scripts:
Eventually buildall will manage all the other top level things like building the distributables. For now I'll just manually create a zip as the distributable.