"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
