No problem Alan I'm busy with the wxWidgets stuff at the moment, which is why I posted it to the list rather than trying to fix it myself.
Something that might be useful though, would be a warning if the paths don't match, just stating that if the user didn't do this intentionally then they can fix it by deleting their CMakeCache.txt. I would have to fish out the docs for string comparison to do it, but if I find time I will - in the meantime feel free to nick this off my to do list if it is very quick for you with your much better cmake knowledge. Phil On 16 January 2015 at 20:06, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > On 2015-01-16 10:50-0000 Phil Rosenberg wrote: > >> Hi Alan >> This may be something you might want to look at, but you might also >> decide to just live with it. If I run cmake without setting >> -DINSTALL_PREFIX, then run it again but do set -DINSTALL_PREFIX >> without clearing my build directory, then all the install paths are >> not changed. >> >> I know it is a minor thing, but it hinders the "it just works" concept >> that I guess we should aim for. >> >> I'm just reporting it so you know - as I said if you don't think it's >> worth worrying about then don't worry about it. > > > Hi Phil: > > I assume you actually meant CMAKE_INSTALL_PREFIX (rather than > INSTALL_PREFIX which is meaningless to CMake) above. > > But regardless of that question, this is a really tricky area that > has some strange idiosyncrasies so for now it is best just to > rebuild the whole project from scratch if you need to change > the install prefix. > > The strange idiosyncracsies are due to the fact this part of the > PLplot build system was implemented in the very early days when CMake > didn't have very good capabilities concerning install paths > complicated by the fact that I made some bad initial choices (e.g., > using absolute install paths as in cmake/modules/instdirs.cmake rather > than relative install paths). > > I think there is likely now a way out of this mess with modern CMake > features so it would become much easier for users to adjust install > paths without rebuilding the whole project. Unfortunately, I don't > have time to tackle this anytime soon, but I wouldn't stand in the way > if someone else wanted to deal with this (so long as the result was > reliable). > > The first step in such a project would be to see how the CMake-based > build system for other projects (e.g., CMake itself) dealt with this > issue. And to ask on the CMake list for what the build-system > developers there feel is the best method of handling a whole bunch of > different install locations (as in cmake/modules/instdirs.cmake) in a > way that makes it easier for users to change the install prefix > of those locations. > > Alan > > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ ------------------------------------------------------------------------------ New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
