On Tue, Mar 03, 2009 at 03:44:45PM -0800, Alan Irwin wrote: > On 2009-03-03 12:49-0000 Andrew Ross wrote: > >> On Mon, Mar 02, 2009 at 11:16:37AM -0800, Alan Irwin wrote: >>> [...]In sum, my advice [to Thomas was] to stick with CMake (since we should >>> be able to give >>> you some help in that case, and CMake skill with a normal build environment >>> and also a cross-build environment is worth developing in its own right), >>> and take it one step at a time. Do the simplest cross-build first with no >>> dependencies. Once that works, start adding dependencies to your cross-build >>> in small steps until you achieve the cross-build that you desire. >> >> Thomas, >> >> I've now done the necessary changes to plplot to allow a cmake >> cross-compilation of at least the basic library. See the plplot wiki >> http://www.miscdebris.net/plplot_wiki/index.php?title=Main_Page >> for instructions. I have cross-compiled for mingw32 under linux. Note that I >> have not tested the resulting binaries, but the compilation progresses >> cleanly. It would be good if you (and others) could try this approach. The >> only change required was to pick up build-time executables from a native >> build rather than the cross-compiled build. PLplot uses these in several >> places to generate data / source code for the build. > > Andrew, I really appreciate you working out the initial cross-build issues. > That proof of concept for the simple case encourages me to think that CMake > is up to the full cross-build job for all aspects of PLplot where the > appropriate non-native libraries are available. > > I have thought of some issues for the get-drv-info case. How does > a Linux-built get-drv-info executable work at all for a shared object > (cross-)built for Windows with MinGW? (Apparently it worked for you, but I > don't understand why.) Also, looking forward to the more complicated case > where the driver has dependencies, how does a native built get-drv-info > using the native libraries libltdl and libdl check the linking of the > non-native device driver plug-ins against non-native libraries? Unless > I missed something, that is going to be a showstopper for that method.
I agree this needs more work. Generating the qsastime header and the hershey font tables should be fine using the native version of the executable. get-drv-info is more tricky. > In case I am right, one way out of the mess is to build get-drv-info on the > non-native platform and also run it (say via ssh) on the non-native platform > with the non-native libraries. If you think that is a good alternative, > then we could revert all your build-time executable changes (in particular > restoring the LOCATION method, see further comment below), and run the > cross-built build executables in the non-native environment instead. In principle I'm edgy about the ssh route. This would not be available for windows which is likely to be one major cross-compilation requirement. An alternative for windows cross-compiles might be wine. This is looking potentially messy though. The reason I made the LOCATION method changes is that this was the recommendation on the cmake wiki. It implied that under cmake 2.6 the command name in add_custom_command was interpreted as a target name and so all the dependencies and platform-specific suffixes were handled automatically so LOCATION was not needed. Of course this needs checking. > > However, if it turns out that you really do need build-time executables > built natively, then I understand why you have to refer to the executable by > some alternative means for the cross-build case, but I would like to see the > LOCATION method restored for ordinary non-cross build case. That is > essential for Windows (where you have an executable suffix to keep track of > and I think there were other issues as well), and the LOCATION method just > makes life easier all around for dealing with dependencies, for example. If it proves a problem we can probably work around it, but I was unclear how to get the LOCATION method to work in a cross-compiling environment. It certainly didn't work by default - I tried. >> >> The current stumbling block for the cairo drivers is that they use >> pkg-config to get the correct paths and libraries to link in. This won't >> work on a cross-compiled environment unless you provide suitable pkg-config >> files from a cross-compiled version of cairo. This should be possible >> though. > > Yes. This may already be covered in the CMake cross-build wiki, but instead > of setting PKG_CONFIG_PATH (which always sets the native pkg-config default > path in addition to the non-native one you set), you should set > PKG_CONFIG_LIBDIR (which sets only the non-native path that you specify and > which excludes the native pkg-config path). I assumed something like this was the case, but not having any other libraries to test it with I went with the brute force approach of disabling it. Perhaps someone could update the wiki with instructions for this? Andrew ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
