Re: [CsMain] MSVC Project file generation.

[Eric S. <sun...@su...>]

On Sat, 22 Nov 2003 08:36:38 +1100, Brendon Costa wrote:
> I have recently been looking at the MSVC project file generation for CS and
> how to apply it to other projects that use CS. I have a few questions and
> requests for changes to the current CS system that might make it more
> simple for other projects using CS to use the same build structure.

Note that there are still a number of problems which need to be resolved  
with the MSVC project generation from Jam.  The Jam system is not yet as  
capable as the make system when it comes to generating project files.  You  
can find a list of most of the problems at the top of CS/mk/jam/msvcgen.jam.   
Please feel free to help resolve these pending issues.  Also search  
CS/docs/jam_todo.txt for "msvc" to find other issues regarding project  
generation from Jam. There are also one or two "tracker" items about this  
issue at www.sf.net/projects/crystal.

> The biggest problem I have come across for other projects is that a few
> things are hard coded in a way that makes maintenance of the build system
> for sub projects slightly painful. Most of what I mention below is so that
> it would be possible to just copy CS's current mk/jam and mk/msvcgen
> directories (among others) into the new sub project to get it to work. If
> there are as few changes as possible to be made to the files in those
> directories to get them to work with the sub project, then it means that as
> CS maintains it build system, then the sub projects only have to copy the
> modified files across without having to worry about maintaining any changes
> they have made for their project.

It has always been the intention that the Jam files should be as  
project-neutral as possible, thus eliminating hard-coded assumptions is a  
good idea.  Making it possible for projects to copy the Jam files verbatim is  
exactly the goal under which we have been striving.

> 1) Currently using jam to add additional directories in the current project
> to the include path, there is a
> IncludeDir $(TOP)/... ...
> statement in the Jamrules file. This is a great idea. The problem is that
> for MSVC project files, this include path is hard coded into the template
> files. If we need to add or modify this search path in a sub project, then
> the need arises to modify most all of the template files for both MSVC 6
> and MSVC 7 to have that include path. Is it possible to modify the current
> perl script (unfortunately I don't know any perl at all) to add additional
> directories to the search path using the same method it does for other
> things (text substitution)? It would mean that the IncludeDir rule for jam
> would need to be overridden for MSVC project generation and the variables
> passed to the rule need to be parsed looking for additional directories
> within the current project and removing the prefix from them, then pass
> this info to the perl script somehow.

msvcgen.pl can already support this with its --cflags option.  One approach  
is to override IncludeDir and have it add a '/i "whatever/path"' to --cflags.  
 This is not quite the same as the "AdditionalIncludeDirectories" key in the  
MSVC7 project file, but it should achieve the same result.  Alternately, the  
Perl script could be augmented to support additional template variables, but  
this is a lot more work and may be a less generic solution.

> 2) In the mk/jam/msvcgen.jam file, the csall workspace name is hard coded.
> Would it be possible to have this as a variable defined somewhere else. For
> example have the main project name equal to the value of $(PACKAGE.NAME)
> which is defined in the Jamconfig file by configure to be "crystal" for
> crystal space and "Planeshift" for planeshift?

Yes, this can be changed.  I would not force it to use $(PACKAGE.NAME).   
Instead, I would make this the fallback option (using ?=) if the project has  
not specified a name explicitly.  For Crystal Space, CS/Jamrules would be the  
appropriate place to set this new variable to 'csall'.

> 3) In mk/jam/msvcgen.jam there are variables to the scripts
> mkverres.sh
> mkmetadatares.sh
> mergeres.sh
> These scripts are located in
> libs/cssys/win32/
> Would it be better to have them in
> mk/jam/msvcgen/

These scripts should not be used by msvcgen.jam at all.  One of the  
important goals of the Jam system in comparison to the CS make system is that  
the Jam system should not have dependency upon external scripts like these.   
You will find, for instance, that win32.jam has already been freed from  
depending upon these scripts; it performs all these actions internally,  
instead of running external scripts.  I suspect that the code in win32.jam  
can be generalized enough (if it is not already) so that it can be used by  
msvcgen.jam, as well.  If you look through the Jam files, you will also find  
a number of other places where we have eliminated dependency upon external  
scripts.  The upshot is that, once msvcgen.jam is freed of these  
dependencies, your above question becomes moot.

(Note that the msvcgen.pl script is an exception, presently, to the rule of  
removing dependencies upon external scripts.  It is probably okay to retain  
this dependency, although I suspect that we can perform a lot of the same  
functionality from Jam; however I am not convinced that using Jam for this  
purpose would be ideal.)

> 4) There was one other thing I am unsure about. Currently when we use
> msvcgen.sh to automatically generate the project files,

I think that, in the future, this script should be retired (it's an ugly  
anomaly).  Instead, the entire procedure should be invoked via standard Jam  
targets.

> Currently the msvcgen.jam file sets the
> rcpath (Path to put the rc files for the project) as
> ../../../$(MSVCGEN_DIRECTORY)/$(msvcname:S=.rc) ; this goes back three
> levels because it seems that the perl script or something in the generation
> command adds the output directory of the rc files path to the path given
> for the rc files internally in the project files. So the path becomes:
> ..\..\out\mk\fragment6\..\..\..\mk\visualc6\whatever.rc
> instead of
> ..\..\mk\visualc6\whatever.rc
> Is there any possible way of fixing this (I think it
> involves looking at the perl script)?

This is not a problem with the Perl script.  The script inserts whatever  
pathnames it is given.  This sounds more like a problem with msvcgen.jam.  It  
either needs to pass the appropriate pathname for the .rc file (the exact  
name that you want to have appear in the project file), or it needs to use  
msvcgen.pl's --strip-root option to adjust the incoming pathnames.  Jam is  
sufficiently expressive to fix this problem without having to resort to  
--strip-root, so I suggest fixing msvcgen.jam to pass in the proper  
pathnames.

-- ES