From: Geoff A. <geo...@ho...> - 2006-03-22 18:50:00
|
As you know, the file NEEDED to compile FG is config.h. Several years back this was COPIED from config.h-msvc6, like what is done in many other open projects ... this is common ... people get used to this ... Of course, they can be very puzzled why, unless they are also quite familiar with the *nix, and cygwin 'automake' environments ... that some header.h.in is used to generate a header.h, with corrections, depending on what was found during a header file search ... but, ok, that can be understood ... Another point I was going to make about the newer config.h-msvc6.in is that is does contain an AUTOMAKE macro - @VERSION@ - If you want to KEEP this for use with cygwin, that is fine. Then why not put back a config.h-msvc6, just for the MSVC environment, with NO automake macro ... >If you run ./configure, the config.h-msvc is generated >from config.h-msvc.in ( you need cygwin installed ). Why would cygwin need config.h-msvc generated from config.h-msvc.in? cygwin generates config.h, the main file, from config.h.in, no? Why would cygwin need to 'generate' an intermediate file that it does not use ... plays no part in a cygwin build? ... And even the suggested 'run ./configure' would lead you to a cygwin mess ... just like in the MSVC environment, the folder where you loaded certain things IS VERY important, thus you need to run, something like - $ ./configure -prefix=/fg-cvs to generate the correct folder placement of items ... But this is all in the cygwin environment. Nothing really to do with raw a MSVC compile ... I hope it is not suggested a MSVC user download and install cygwin JUST to generate config.h-msvc so MSVC can use a custom make step to COPY this to config.h ... ;=)) >* They don't work as is. This is agreed, but they are a good START ;=)) Due to many things, like where did you download PLIB, Simgear, zlib, OpenAL, etc, ... almost nothing would work out of the box, including any SLN/VCPROJ files, if provided ... unless you 'conform' 100% to the folder structure chosen by the SLN/VCPROJ providers ... And for example, I note from Olaf's site, the addition of pthreads, and freeglut ... other folders locations that would be important ... that must be 'correct' to suit the given SG/FG SLN/VCPROJ files ... >* The dsw files are for VC6. Visual C 6 does not >compile FlightGear (any more). As recently as a few months ago, I assisted a person, (offline) to compile using MSVC6. It does require some code 'work' to do this, but it is POSSIBLE ... none of this has been put forward as a 'change' in the CVS code ... so why should you care? Yes, you can suggest they download other 'tools', new 'tools' etc ... but also why not let them use what they have ... >* They don't even work for newer Visual Studios >(Dependencies are broken: Microsofts Fault, not >our's) Not sure how this is related to removing the DSW/DSP file, or what is exactly refered to here. If it is refer to the fact that MSVC7.1, and perhaps 8, no longer seem to keep as good a automatic track of dependencies as good old MSVC6, then, as a 'developer' you get used to using 'remake all' ;=)) actually, I more frequently use the 'batch mode' ... But why is this any reason for removing this set of DSW/DSP files, automatically generated? >* IMHO No developer uses them. As I suggested, 'developers' tend to find their own way ... have their own preferences, etc ... it is for the new, first time users that I want to encourage to 'become' developers that I feel for ... that need help ... These DSW/DSP files can be automatically generated by am2dsp.pl, enhanced fractionally a few months ago by Fred, using am2dsp.cfg, thus can be the first indication that a new file has been added, or some source removed ... or you can read/view the raw Makefile.am files directly ... They do work for MSVC7.1 ... it provides a good 'conversion' to its new xml format, leaving the DSW/DSP alone ... do not know about MSVC8, since I have yet to BUY, and use this extensively ... I have tried a few times with the 'express' (free for now) version, and it did a similar 'conversion' ... This is good in that in a CVS update, you can quickly compare your old with the new, to see if you need to update your SLN/VCPROJ files ... if that is what you use ... >I would vote for including Fred's VC7.1 and/or >my VC8 project files from http://www.oflebbe.de/oflebbe/FlightGear. There >are surely some pitfalls I too have MSVC7.1 *AND* MSVC6 build file on my site - http://www.geoffmclane.com/fg/ - this is purely a factor of how frequently you 'update' your site ... or the cvs, if put in cvs. Sure Fred and Olaf want to move on ... then I agree perhaps the SLN/VCPROJ files should also be added to the CVS source, but that is no reason to delete the auto-generated, partial, incomplete, DSW/DSP files from CVS ... let all forms live ;=)) So what am I suggesting? Simply, that a config.h-msvc file be returned to cvs, so the current custom step in am2dsp.cfg works! And that, that file NOT contain an automake macro - @VERSION@ ... If you want to call it config.h-msvc6, then ok ... the name does not matter, so long as the name matches the 'custom' step in am2dsp.cfg ... it should be NOTHING to do with what is provided specifically for the cygwin environment ... DSW/DSP files have naught to do with cygwin ... Should we abandon MSVC6? That is up to the community ... we have already, in a way, in that some of the code syntax no longer can not be compiled with MSVC6 ... but I, and perhaps others, ARE willing to help people with this ... IT IS POSSIBLE ... Recently, with the addition of mk_viii.cxx, which was the first file to include "version.h", adds to this complexity. This file is generated by 'automake', using "version.h.in", which ALSO includes an automake macro @VERSION@ ... But as yet, there is no MSVC 'custom' build, to COPY this file, in the DSP file ... and MSVC, non-cygwin users, must do this step MANUALLY ... Even if there was, it would NOT expand the @VERSION@ ... so this file MUST be manually COPIED by MSVC users, and, if thought necessary, fix the @VERSION@ ... And if you begin, as a MSVC user, to be concerned about MSVC 'warnings', then you would note a warning about the redefinition of - #define FLIGHTGEAR_VERSION "@VERSION@" which is also in config.h-msvc6, presently named config.h-msvc.in ... one, or the other should have - #ifndef FLIGHTGEAR_VERSION casing around it ... Simply, to move on - yes! * Abandon the very good, efficient, 'autogen' of DSW/DSP files - no! * Correct the file names and the custom step to match - yes ;-)) * Do something about 'version.h.in' - that can wait ;=(( * Add MSVC7.1 or 8, or BOTH, SLN/VCPROJ files - yes, why not ... provided someone can be 'in charge' of keeping them as up to date as possible ... or a similar am2vcproj.pl be developed ... Regards, Geoff. PS: SimGear - this is a good example - simgear_config.h is COPIED from simgear_config.h.vc5 via a custom build step in SimGear.dsp ... I hope it is noted, this was built during the MSVC5 epoch, and is still valid today ... for MSVC6, MSVC7.1 AND MSVC8 ... EOF - fg-39.doc _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ |