Re: [Flightgear-devel] JSBSim and MSVC
Christian Mayer wrote: Off course. As I wrote in my mail it's no problem to add additional include/library directories. But I don't see a reason to add K:\Projekte\SimGear\simgear\zlib or ..\SimGear\simgear\zlib to the include directory. The include directory should have only intuitive directories. I still see no reason why the additional #ifdef is so much more confusing than adding an arbitrary include directory. This seems like a silly argument. We have two choices: + Change the include line with an #ifdef for MSVC. + Change the include path in the MSVC project. Both of these are trivially easy. One of them is an annoyance to MSVC users. The other is an annoyance to everyone, including MSVC users. I vote to annoy as few people as possible. :) Seriously, why is adding a SimGear include directory to the include path non-intuitive. When you write a program using third party libraries with MSVC (and zlib is definitely a third party library), what do you do? That's right, add their install directories to the include path. This is normal practice, even in the windows world. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim and MSVC
Christian Mayer writes: PS: So there's just the #include zlib.h issue left to be fully MSVC friendly... Typically in the unix world, you would install packages like zlib into a place where the compiler expects to see them, or some other place and inform the compiler where to look. In the linux world, the packaged version of zlib would typically install the library in /usr/lib/libzlib.a and the header in /usr/include/zlib.h If you were compiling and building the package from source yourself, the convention is 'usually' that you put it in /usr/local, so /usr/local/lib/libzlib.a and /usr/local/include/zlib.h The configure script automatically tells the make system to tell the command line compiler to look in /usr/local/ for includes and libs: -I/usr/local/include and -L/usr/local/lib I would think that in MSVC you should be able to do something analogous. Either install the libs and headers someplace where the MSVC compiler expects to find these things, or install them someplace else and tell the compiler where to find them. I don't consider this an 'issue' with flightgear or simgear unless you tell me MSVC is absolutely not capable of handling user installed libs and headers ... and in that case we would be forced to come up with some work around. zlib is a very nice library which is worth installing 'system wide' so it is avaible for use with any software you are building. Regards, Curt. -- Curtis Olson Intelligent Vehicles Lab FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim and MSVC
Curtis L. Olson writes: Christian Mayer writes: PS: So there's just the #include zlib.h issue left to be fully MSVC friendly... Typically in the unix world, you would install packages like zlib into a place where the compiler expects to see them, or some other place and inform the compiler where to look. In the linux world, the packaged version of zlib would typically install the library in /usr/lib/libzlib.a and the header in /usr/include/zlib.h If you were compiling and building the package from source yourself, the convention is 'usually' that you put it in /usr/local, so /usr/local/lib/libzlib.a and /usr/local/include/zlib.h The configure script automatically tells the make system to tell the command line compiler to look in /usr/local/ for includes and libs: -I/usr/local/include and -L/usr/local/lib I would think that in MSVC you should be able to do something analogous. Either install the libs and headers someplace where the MSVC compiler expects to find these things, or install them someplace else and tell the compiler where to find them. Surely you can just put libzlib.a in vc\lib and zlib.h in vc\include? Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim and MSVC
Curtis L. Olson wrote: Christian Mayer writes: PS: So there's just the #include zlib.h issue left to be fully MSVC friendly... Typically in the unix world, you would install packages like zlib into a place where the compiler expects to see them, or some other place and inform the compiler where to look. [...] Let's see: All the headers that are shiped with MSVC end up at D:\Programme\Microsoft Visual Studio\VC98\Include (that's becaue all my programs end up in D:\Programme) and all shiped libraries and up in D:\Programme\Microsoft Visual Studio\VC98\Lib These directories are standard, so any MSVC C program finds them. (If I'd use any other compiler it wouldn't find anything as there's no Unix-like standard where these files go; that's OK as Windos doesn't come with a compiler and a user won't need these files) As there's no standard I'm allowed to make my own. E.g. all my projects live (currently) in K:\Projekte\whatever (e.g. K:\Projekte\FlightGear and K:\Projekte\SimGear) So compiling a new library I can do: either 1) copy the results (.h and .lib) into D:\Programme\[...] (either by hand or create a custom build step that does that) so that every other program finds these files or 2) leave them where they are and add the necessary include paths (one for the compiler and one for the linker) I don't like 1) as I don't have any distinction between official libaries and my own libraries (that's not only for me important, or why does Unix have /usr/lib/ and /usr/local/lib/?). In the event that I have to install everything again (e.g. headcrash) I also would wonder (at the beginning) why SimGear wouldn't compile although it did all the time. I'd *really* want to avoid that. 2) is what I'm already using. The FlightGear workspace does include ..\SimGear in the search path and thus finds e.g. K:\Projekte\FlightGear\..\SimGear\simgear\bucket\newbucket.hxx without any problems. This used to work with zlib (which isn't standard under Windos and thus shouldn't go to D:\Programme\Microsoft Visual Studio\VC98\Lib) So what I *could* do is to create, say K:\semi_official_libraries and put zlib there and include K:\semi_official_libraries to my search path. That's a *bad* idea, as a program has no right to force me to stick to its idea of my system setup. The only right it has is to say: I'm sticking to this official standard (say e.g. LSB) and when you don't like that standard it's your problem that you've got additional work. But there's no such standard under Windos, so it can't tell me to stick to it. So I see two possible practical solutions: 1) Drop ZLIB completely from SimGear and tell the user to get it themselves. (I'd put it like every other library in K:\Projekte\ and add ..\zlib to the path) 2) Add the few #ifdefs as they've been there already and leave zlib in SimGear. Leaving ZLIB in SimGear and telling the people to do 1) is IMHO very confusing. Defintely much more than a #ifdef HAVE_NO_ZLIB CU, Christian PS: Alternative for 1) is to have it completely in the zip archive (as alredy done) and get rid of the SimGear/simgear/zlib directory. PPS: No need to mention that I'd prefer the no-additional-work (and thus getting too confused) solution 2)... -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
