Here are some more resources on configuration/building for cross-platform projects: There's a lot of work going on in Python for cross-platform development, management, and distribution as part of their distutils project (http://www.python.org/sigs/distutils-sig/doc/). This is geared towards command-line builds driven by Python, not making .dsp files for devstudio. Right now, there are not good general purpose cross-platform tools. This is part of what the Software Carpentry project (Open Source, Open Science) was created for (http://software-carpentry.codesourcery.com/). They aim to replace make, autoconf, bugzilla, and various unit-testing programs with a set of cross-platform tools (Windows NT and Unix) that will simplify the process of building and maintaining large projects by scientists who want to use scientific software to do science rather than spending weeks or months tinkering with autoconf and make scripts. However, this project has just finalized the design documents for three tools and is preparing to enter the development stage. They have some real money to pay for development, but it will be a while before they have anything usable. Concerned people in the ROOT community may want to contribute their skills to this. There is some useful information in some of the design documents submitted to the Software Carpentry competition. Particularly, the submissions from ActiveState for build and configure tools (Black and Tan, respectively) propose XML representations to replace makefiles and autoconf files. These documents (http://software-carpentry.codesourcery.com/entries/second-round/build/Black/ and http://software-carpentry.codesourcery.com/entries/second-round/config/Tan/) may be useful to Matthew. VTK brute-forces the cross-platform issue with a special-purpose Visual C++ program that reads the autoconf files and creates a makefile for the Microsoft build tools (makefiles for nmake, not .dsp files for devstudio). On the specific topic of .dsp files for building root extension classes with VC++, one real problem I have had trying to build root extension classes from inside VC++ is that the DevStudio IDE isn't really sufficiently flexible to handle tools that output C or C++ source and header files (lex, yacc, rootcint, etc.). You can brute force it with custom build rules, but I haven't found an elegant way to deal with these kinds of things and get DevStudio to understand all the dependencies correctly, so I always end up writing makefiles. You can always make a .dsp project that itself contains one file: the makefile and a custom build rule that invokes nmake. This lets you compile from within the IDE and jump to errors, but does not let you use the class view or view a list of dependencies from the IDE. Hope that some of this may be useful. Jonathan At 07:46 PM 11/11/00, Valeri Fine (Faine) wrote: > 2. Another question how to manage "cross" platform project? > So far the only "good" solution we found is the perl script. It is > so-called "cons" Perl package. > Perl for Windows is available from www.activestate.com, "cons" is a > regular "perl" script > available by "ppm" for example. >----- Original Message ----- >From: Matthew D. Langston <langston@SLAC.stanford.edu> >To: roottalk <roottalk@pcroot.cern.ch> >Sent: 11 ноября 2000 г. 16:17 >Subject: [ROOT] VC++ project files for ROOT and a rootcint add-in ... > > It would make sense to want ROOT's project description files for VC++ to > > automatically be kept in sync with the UNIX project description files (i.e. > > the *.mk files and the associated UNIX+make build procedure). This sounds > > like a lot of work. One idea would be to describe the ROOT build procedure > > in an XML file so that project description files could be automatically > > generated for any build system (i.e. ROOT's current UNIX+make build system, > > the VC++ build system, the KDevelop build system, an Automake build system, > > and any other build system that might come down the pipe which users may > > need). > > > > I don't know of any XML schema for describing software build systems, but I > > haven't looked that hard either. Does anyone else? If such a schema > > existed, then maybe it would make sense to use it to describe the ROOT > > project database and build system. We could then trivially add support for > > multiple build systems by writing simple XSLT templates for each build > > system. =========================================================================== Jonathan M. Gilligan jonathan.gilligan@vanderbilt.edu
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:39 MET