Hi Alan thanks for all that, I'll sort out the commit asap - you will
presumably see the commit alert.
>However, you have to clearly
distinguish what we tell CMake to do via our CMake build system logic
compared with the actual build result that is generated by CMake (and
which you access using the VERBOSE=1 option in the nmake case, but I
don't know what is required in the VS case). For example, it is often
the case that an app links to a library which links to other libraries
the app is completely unaware of. (For example, our C examples link
to the plplot core library but are completely unaware that that
library has other library dependencies since the app uses nothing
directly from those other libraries.) For this case in CMake you only
express direct library dependencies in the target_link_libraries
statement and ignore the indirectly linked ones. Then CMake
(including the particular generator logic you are using) is supposed
to translate that information into something that is correct for the
platform, i.e., some platforms like Linux are completely happy with
mentioning only directly linked libraries (so-called non-transitive
linking) to the linker while others demand all directly and indirectly
linked libraries are mentioned, i.e., so-called transitive linking.
So on Windows either is acceptable - at least for static libs, dlls are a bit
different. I can either link a library into a depending library then link this
into my exe, or I can not link the libraries together and can link them all
into the exe. One might prefer the former if multiple versions of the same
library are required in one exe (e.g. imagine plplot only supported wxWidgets
2.8, but my exe used 3.0). What confused me is that CMAKE does neither of these
- it appears that we tell it to link dependancies into plplot, but it doesn't,
then when we tell it to link plplot into the examples it links plplot and the
dependancies. This situation works fine and there is nothing to be done by hand
- it just rather confused me as it isn't behaviour that corresponds to anything
that can be done natively.
Regarding Windows issues - yes I basically agree. I have Cygwin now and it is
very useful. I now put all my open source code and libs in a Linux style tree
(separate to Cygwin) with a src, bin, lib, etc structure. The reason for the
separation is that libraries built with VC++ use a different runtime to those
built with gcc, so although mixing the two can be done, it is easier to keep
them separate. Of course by setting up a tree like this with libs all together
puts the requirement upon me to manually manage dll hell - which is why I
almost solely use static libs. I don't know the details of how it "should be
done" on Windows. Probably some combination of registering libraries with the
side-by-side service and using the MS installer which I think tracks dlls
somehow. I doubt many open source libraries do any of these things as most are
more Linux-centric.
Thanks again for all your help Alan - sorry if my last email sounded a bit
grumpy.
Phil
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
