Re: [Flightgear-devel] FlightGear/SimGear dsp/dsw files
Olaf Flebbe wrote : > Hi, > > sorry for the delay > > I second that config.h-msvc6.in (having cygwin to compile MSVC) is plain > silly. > > You may have noticed that the Version in CVS has a config.h-msvc8 > without the @VERSION@ madness. > Call it silly or madness if you want. In the meantime, you don't resolve the issue that this file never had the right version in every tarball made by Curt before that. -Fred -- Frédéric Bouvier http://frfoto.free.fr Photo gallery - album photo http://www.fotolia.fr/p/2278 Other photo gallery http://fgsd.sourceforge.net/ FlightGear Scenery Designer --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/SimGear dsp/dsw files
Hi, sorry for the delay I second that config.h-msvc6.in (having cygwin to compile MSVC) is plain silly. You may have noticed that the Version in CVS has a config.h-msvc8 without the @VERSION@ madness. ... > >* 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? The point is: If you generate Project files from scratch, dependencies work. But somehow dependencies do not work when importing the *dsp/dsw from FlightGear. On the other side: SimGear does work. I tried to fix this behaviour but didn't succeeeded. It is a lot easier to support new files than the automagic conversion process using undocumented file formats which work, sometimes. > 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 I suggested one of the fixes applied, but realised later that the files are broken more severely, and gave up. ... ... do not know about MSVC8, since > I have yet to BUY, and use this extensively ... I There is almost no difference between the express and the professional version. (It has MFC, ATL and masm included, and offline help) > 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. I would be happy to get something more useable into FlightGear. I am only insisting to get something usable into FlightGear. > 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@ ... Yes, please. > 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 ... Yes, it is possible, but IMHO it does not make sense. > > 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@ ... IMHO The version.h file is plain silly. Please remove from CVS and include the info back into the config.h. > Simply, to move on - yes! > * Abandon the very good, efficient, 'autogen' > of DSW/DSP files - no! Efficient? The converted vcproj file is over 300kb large. The hand crafted is 8 kb. VC8 is dead slow using the converted one. Olaf --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/SimGear dsp/dsw files
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
Re: [Flightgear-devel] FlightGear/SimGear dsp/dsw files
Please delete the dsw/dsp files for four reasons:* They don't work as is.* The dsw files are for VC6. Visual C 6 does not compile FlightGear (any more). * They don't even work for newer Visual Studios (Dependencies are broken: Microsofts Fault, not our's) * IMHO No developer uses them.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 left for others. Cheers Olaf
Re: [Flightgear-devel] FlightGear/SimGear dsp/dsw files
Geoff Air a écrit : > > Just a small point, but it could bother > some new people ... when you load MSVC7.1 > using the FlightGear.dsw (and dsp), you > can be blocked from a compile by a > custom step, which presently fails ... > > The am2dsp.cfg file contains a custom - > # Rule to create config.h > which gets included when am2dsp.pl is > run, but at present this custom step > tries to copy from - > > config.h-msvc to config.h > > This is certainly what it used to be called, > when I last updated it in July 2003, but quite > some time ago this file name disappeared, > and was replaced with - > > config.h-msvc.in > > same file contents however ... > > Could we either - > (a) adjust the FG am2dsp.cfg file to > reflect this changed name, or > (b) put the file back as config.h-msvc, > as it was originally. > > It is agreed most of us no longer depend > on the DSW/DSP provided, since perhaps like > me, we update our SLN/VCPROJ files when new > files appear in a CVS update ... but new > people probably still commence with these > old file ... and this 'error' does block > a compile ... If you run ./configure, the config.h-msvc is generated from config.h-msvc.in ( you need cygwin installed ). This is because the version in that file is never updated otherwise. If you try to compile from a released tarball, this file ( config.h-msvc ) should be included. -Fred -- Frédéric Bouvier http://frfoto.free.fr Photo gallery - album photo http://www.fotolia.fr/p/2278 Other photo gallery http://fgsd.sourceforge.net/ FlightGear Scenery Designer --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/SimGear dsp/dsw files
Just a small point, but it could bother some new people ... when you load MSVC7.1 using the FlightGear.dsw (and dsp), you can be blocked from a compile by a custom step, which presently fails ... The am2dsp.cfg file contains a custom - # Rule to create config.h which gets included when am2dsp.pl is run, but at present this custom step tries to copy from - config.h-msvc to config.h This is certainly what it used to be called, when I last updated it in July 2003, but quite some time ago this file name disappeared, and was replaced with - config.h-msvc.in same file contents however ... Could we either - (a) adjust the FG am2dsp.cfg file to reflect this changed name, or (b) put the file back as config.h-msvc, as it was originally. It is agreed most of us no longer depend on the DSW/DSP provided, since perhaps like me, we update our SLN/VCPROJ files when new files appear in a CVS update ... but new people probably still commence with these old file ... and this 'error' does block a compile ... Regards, Geoff. EOF - fg-38.doc _ Don't just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/SimGear dsp/dsw files
Curtis L. Olson wrote : > Currently whenever I run "make dist" to roll up a new tarball release > of FlightGear or SimGear the am2dsp.pl and new dsp/dsw files are > generated. Now that we have a couple active MSVC developers who track > the cvs changes and maintain their own version of these files, does it > make sense to keep autogenerating dsp/dsw files or just use the > manually crafted versions? Keep them for now. Our crafted versions are not in CVS yet. I will try to update the generated one more often. -Fred -- Frédéric Bouvier http://frfoto.free.fr Photo gallery - album photo http://www.fotolia.fr/p/2278 Other photo gallery http://fgsd.sourceforge.net/ FlightGear Scenery Designer --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FlightGear/SimGear dsp/dsw files
Currently whenever I run "make dist" to roll up a new tarball release of FlightGear or SimGear the am2dsp.pl and new dsp/dsw files are generated. Now that we have a couple active MSVC developers who track the cvs changes and maintain their own version of these files, does it make sense to keep autogenerating dsp/dsw files or just use the manually crafted versions? Thanks, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
