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/
-------------------------------------------------------
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
