On 25 Oct 2011, at 15:20, Geoff McLane wrote: > > >> need to see the arguments / environment >> passed to CMake, to understand why. > But in each case I have explicitly given you > the exact exports and cmake commands used... > > What more do you need?
The problem is you've confused me, with all the discussion :) So it would help, to be able to see exactly the commands, all of them, in one place - maybe upload your scripts to someplace? Then I can get an overview of what you're doing. > 1. can NOT compile sgsound due to NOT finding > <AL/al.h> > > Of course I can manually fix this in the > MSVC IDE, *OR* I could COPY AL/al.h to the > '3rdparty/include' I am using, that already > contains many other of the 3rd party > dependents... > > But the 'correct' fix would be for the > CMake GUI ask where to find it... > > How can I do this? Seems like a bug in the FindOpenAL module (we use the standard CMake one) - might need to report it upstream. We can fork the script locally, and add support, but I wonder why other Windows users didn't report this. Maybe they all use Fred's standard dependencies package? > > 2. It fails on linking test_binobj, > Configuration Debug, with link error > LNK2005: LIBCMT.lib conflicts with LIBCMTD.lib... > > But this does not make sense. It is building > the Debug configuration, so why has it linked > also with the NON-Debug version... > > Why did it NOT apply that rule in this > case? Is there something I can change in > the CMakeLists.txt files to make this > happen? The problem is library detection, not generation (so changing the postifx won't help - it only affects the libraries that are produced). Again it may be an issue with the FindZLib module on Windows - I don't run Windows so not really able to say. On Unix, CMake will use both the debug and release versions if it finds them, otherwise it will use the release (no suffix) version for everything. That's fine on Unix, but obviously not on Windows, since the runtimes clash as you described. > > 3. Question of library output directory > > > But at present it is outputting the libraries to > C:/FG/30/simgear/build/simgear/io/debug/sgiod.lib > and > C:/FG/30/simgear/build/simgear/io/release/sgio.lib > > Ideally I would 'like' it to output them all to > C:/FG/30/3rdparty/lib/sgiod.lib and > C:/FG/30/3rdparty/lib/sgio.lib > > That is the whole purpose of using this 'd' > for the Debug, to keep the names separate... > thus do NOT want them placed in > .../build/<projects>/<debug|release>/<lib>[d] > > So again, do you know of a way to 'teach' > cmake this little trick ;=)) Can't you just run 'make install'? The build locations are correct, if you want them to end up in their final home, you need to actually perform the install step. Assuming I understand what you're trying to achieve. James ------------------------------------------------------------------------------ The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
