Accumulator Parameter Syntax ---------------------------- Author: Tom Goodale Date: Some time in 2002 To tidy up the external arrangement, and also to make some other things, it would be handy to have a way for thorns to have individual configuration scripts which could be run from the CST. Proposal is the following... We introduce a new CCL file called 'configuration.ccl', or something better if anyone can think of one. This file descibes configuration options and the script(s) to run to configure things. We introduce the concept of 'capabilities', and the a thorn can provide or require a capability, or say it may use if available, to whit 1) PROVIDES IEEEIO { SCRIPT myconfigscript.pl LANG perl } Says that this thorn provides the IEEEIO capability, and that 'myconfigscript.pl' should be run by perl to execute it. If the configuration script doesn't return 0, the CST will print the return code, and stop after all CCL files are processed. The script should write to its stdout lines like DEFINE ... END_DEFINE which puts a #define into an include file to be included by all thorns using this capability INCLUDE_DIRECTORY ... which adds this include directory to the include path whren compiling any thorn using this capability MAKE_DEFINITION ... END_MAKE_DEFINITION which adds lines to be included in the make.code.defn of any thorn which uses this capability MAKE_DEPENDENCY ... END_MAKE_DEPENDENCY which adds lines to be included in the make.code.deps of any thorn which uses this capability LIBRARY LIBRARY_DIRECTORY which add to the LIBS and LIB_DIRS make variables respectively. The script can store configuration data in / so it doesn't have to repeat too much everytime it is called, and will only be called when the thorn is added to the ThornList. The configuration script should be passed, either via a configuration file, or on the command line (probably better to avoid having to parse a config-file) the directory info, and a canonical architecture type. 2) REQUIRES IEEEIO States that this capability must be present. 3) OPTIONAL IEEEIO { DEFINE HAVE_IEEEIO } States that this thorn will use the capability if it is present, and to define HAVE_IEEEIO in a header file included by this thorn. 4) NO_SOURCE States that this thorn has no source files, so the make system shouldn't try to make library for this thorn. The CCL files for this thorn should still be on the dependency list for the CST. Anyway, I think that's the current status of my thinking on how we do this. Tom ------------------------------------------- Excerpt from original discussion mail... What we want is for the thorns in the external arrangement to find a library installed on the system, and if they can't find it, to tell people where thay can download it from. We can then just put a not in the download instructions saying that "for xxxx functionality you need to download yyyy from zzzz". We probably thus need to have an optional 'configure.pl' or 'configure.sh' script in each thorn's top-level directory which should be run from the CST and output lines like LIBRARY_DIR .... LIBRARY .... INCLUDE_DIR .... DEFINE .... MAKE_VARIABLE .... MAKE_DEPENDENCY ...\n\t...\n\t...\n which the CST can then put into appropriate files included from cctk_Config.h and make.config.defn, make.config.deps. The configure scripts could store status information in a config-status directory in each configuration, so they don't have to ask the same questions time and time again. Anyway, this is one possibly workable design, which means a bit more work for users in that they don't automatically get some libraries, but does mean that there is only one copy of each library on each system. We can always allow people to download pre-compiled libraries for each architecture, and have a 'PrecompiledExtLibs' arrangement containing directories for each library and each architecture just to make things nice for people. Tom On Fri, 4 Feb 2000, John Shalf wrote: > > OK, for the rest of this msg... > Thomas or Gab or whoever is maintaining the pserver; here is what I am looking for! > > * I just want to be able to check out FlexIO from the pserver rather than the old AFS-based server we > used for Cactus 3.x development. I don't want anything else with it when I check it out... just FlexIO > in a directory called FlexIO or IEEEIO (just like I got under the old CVS server). Thats all I need. > > * If this same FlexIO can be a module that can be plugged directly into Cactus rather than the two > being distinct repositories, then that's great too. We won't have to periodically update the cactus > stuff with bugfixes that were applied to the master repository. I can rename the old master makefile so > that it doesn't confuse cactus's config process. Thats no problem. I just don't want to have to check > out something called "external" and I don't want a whole bunch of parallel directories coming as part of > this. The net to germany still sucks from here and the fewer files I need to check out; the better for > me. We'll probably have a different version in devcvs than the regular anonymous cvsroot (the dev one > being the version that we change most frequently and the anon one being a working snapshot; that'd be > cool too!). > > * I want to be able to tell the people who are getting FlexIO that they can check it out from the > pserver. Is that OK with you to use the pserver for this? If that's OK, then I'd want FlexIO to be > complete (not just the files for libieeeio.a). Likewise it would be confusing to tell people that they > need to check out a package called "external" which has a bunch of parallel library trees associated > with it. > > Thats all I want notwithstanding all of the discussions about make++, naming conventions, and which > libraries should be build, etc. I just want the base FlexIO package to be available on the pserver in a > manner similar to the old CVS/AFS repos was. > > -john > > Werner Benger wrote: > > > > > > It already has a standalone makefile as part of the package. > > > > > > > > > no longer in the cactus external/ directory, it hasn't survived the transition > > > > from AEI CVS to Cactus CVS (I think Thomas was doing this). > > > > Problem is also that a makefile in the library directory would conflict with > > > > cactus. > > > > > > Well then copy the "Makefile" from the /afs/aei-potsdam.mpg.de/cvsroot/IEEEIO and call it > > > "Makefile.gmake". It works well; it autoconfigures for a wide variety of platforms; and it doesn't > > > require the users to build any other programs to do a build (just type gmake -f Makefile.gmake and > > > it will autoconfigure and build itself). ...Can't beat that.. > > > > > that won't work, because this makefile tries to build all of > > > > libieeeio.a libhlio.a libAMR.a libhdfio.a > > > > but the cactus external repository doesn't contain all files required for this, just the files > > required to build ieeeio.a . > > We could reintroduce the `non-essential' stuff, but I assume that Thomas wanted to have > > it of a more cleaner structure, such that each library has its own subdir. > > > > > > > You can make a "Makefile++" or a "makefile.mcs" which works with make++/MCS in order to > > > > > improve Amira compatability (that would be a good idea), but the existing makefile is simple > > > > > and well tested on many platforms. > > > > > > > > > I usually call them GNUmakefile. This doesn't conflict with cactus and doesn't conflict > > > > with standard makes, but is selected by GNU make in preference to other names. > > > > > > OK, that sounds fine. > > > > > > > > Sure, I have no problem with a parallel set of makefiles that are designed around ZIB Make. > > > > > But I'd still like to keep the current "Makefile" as the default since it requires very little > > > > > external support. > > > > > > > > > so ok, I've added all things required to compile the external libraries > > > > independently of cactus, you may give it a try: > > > > > > > > cvs -d :pserver:@cvs.cactuscode.org:/cactusdevcvs co external > > > > cd external > > > > gmake > > > > > > This is interesting, but not quite what I was thinking about. I was thinking more on the lines of; > > > > > > cvs -d :pserver:cvs_anon@cvs.cactuscode.org:/cactuscvs login > > > >password: anon > > > cvs -d :pserver:cvs_anon@cvs.cactuscode.org:/cactuscvs co FlexIO > > > cd FlexIO > > > gmake > > > > > > It'll just grab the FlexIO package which works fine for Irix, SunOS, HP/UX, Linux, T3E, and Windows > > > without need of compiling any additional packages like make++. Less code is better I think! > > > Likewise, it'll be nice to be able to check TCP++ out independently as well. > > > > > make++ isn't a code which needs to be compiled, it's just a bunch of makefile fragments, > > which are then included in a customizable manner. > > What could be done easily is to create some cvs modules, which checkout IEEEIO, make++ > > and some main GNUmakefile, which does nothing more than compiling FlexIO. > > For using your previous standalone makefile we probably need to decide if > > really multiple libraries are required to reside in the same subdir. > > I suppose this decision is mainly up to Thomas, who did this `extraction' > > originally. > > > > > If they want to use make++, then they can additionally do > > > cvs -d :pserver:cvs_anon@cvs.cactuscode.org:/cactuscvs co make++ > > > or even checkout directly from ZIB. It would seem overly restrictive for your make++ package to > > > have its repository be *underneath* of some unrelated package like FlexIO. > > > > > yes, that's true. I've just put these files to the cactus external such > > that one can conveniently check this out, as it doesn't influence with > > cactus, and at ZIB we don't have an anonymous CVS, so the only way to > > get it from there is to get the .tar.gz file from the webpage; but cvs > > is of course much more convenient. This place (external/make/) is mainly > > thought for some evaluation purpose, if someone else than me ;-) considers > > it to be useful, we can look for a better place, otherwise we can remove > > it also. > > However, basically, it is not be `underneath' of FlexIO, but parallel > > to it. Logically, it's an external component (external/make/), like > > FlexIO is an external component (external/FlexIO/) and this make/ thing > > would be usable by all components (libraries) in the external/ cvs tree, > > like TCPXX and RemoteIO currently. The concept of this stuff is to be > > able to compile various different libraries in a compatible manner. > > If you have multiple libraries in the same subdir, then there is only > > one makefile for all libraries, and compatiblity is ensured. But if > > this is not the case, then somehow the makefiles for each library > > need to be `synchronized', and this is basically what the make++ does. >