Opened 15 years ago
Last modified 15 years ago
#531 assigned task
Change Greenstone2 build code to Ant
| Reported by: | oranfry | Owned by: | oranfry |
|---|---|---|---|
| Priority: | moderate | Milestone: | Greenstone 2 wishlist |
| Component: | Greenstone2 Build Code | Severity: | minor |
| Keywords: | Cc: |
Description
There are some problems with the existing Greenstone2 build system. Currently gsdl is compiled with the usual 'configure, make, make install' in the top level gsdl folder. This will first perform configure on all components, then make all components, then make install all components. This is problematic as the configure part of some components requires the compiled binaries of other components to be present. A better build system would do 'configure, make, make install' on individual components one by one in an appropriate order.
Propose to replace the top level gsdl build files (configure.*, Makefile.*, etc), and those for build-src, runtime-src (and common-src?) and indexers with ant build.xml files, and move the logic for building each component (including any necessary compilation options) into these files.
Also, any java-only components which are controlled by us (ie, gli and maybe some others) could use a build.xml file to replace the existing build code.
We should put a minimal ant distribution into gsdl in the repository, to remove the prerequisite of having ant to compile Greenstone. Could also provide, as an alternative to the build.xml files, the cascadeMake.sh files which davidb has started work on. All this would go in a top level folder inside gsdl.
Change History (2)
comment:1 by , 15 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
Just a thought: a top-level configure script coupled with appropriate caching (of the size of an int, size of a long etc) can save time compiling subcomponents which themselves use configure scripts. If our caching is presently good, then changing to an ant build system could cause a considerable slowdown in compilation. If our caching is currently bad then it won't make too much difference. For the best of both worlds, maybe a hybrid is appropriate: an ant build system but with a "fakey" configure script at the top level which just caches info about the machine for subcomponents to take advantage of.