Mike, I thought that at first I could just set the prefix in my configure script - then I remembered that the binaries are created automatically by an external program that would require some major reconfiguration effort. Plus, users could duplicate HDF binaries if I make it a simple ON/OFF option.
Less effort and a plus - even better if I already have an option I could reuse! Allen On Tuesday, April 22, 2014 11:09:44 AM Michael Jackson wrote: > Not sure what the original problem was but my guess is that you _may_ want > to take care of this outside of the normal HDF5 build system? Of course > saying that, I have some "special" variables in my own projects that if set > I use them to over ride some of the default CMake variables for when I > create SDKs of our project. I think the better solution maybe to have an > external script driving that process (such as another CMake script or Bash > or batch file) and let that external script set the CMAKE_INSTALL_PREFIX. > > Mike Jackson > > On Apr 22, 2014, at 10:53 AM, Allen Byrne <[email protected]> wrote: > > Mike, > > > > Good point! My mistake in confusing generating our binaries vs users > > using > > > > the source code! So obvious now. > > > > The code in question will be removed - however I may need to use the code > > block with a new option to build HDF binaries to address issues I ran into > > that caused the original problem. Need to do some testing. > > > > Allen > > > > On Tuesday, April 22, 2014 10:43:11 AM Michael Jackson wrote: > >> Allen, > >> > >> But all of that is already taken care of by CMake. If the user simply > >> runs > >> > >> cmake without any type of "-D" argument the default on Unix/Linux/OSX is > >> to > >> set CMAKE_INSTALL_PREFIX to /usr/local/hdf5. On windows it will be > >> C:/Program Files/hdf5. So I am not sure what all your code is > >> accomplishing. I think the CMake defaults are reasonable for each > >> platform > >> it is used on. If the developer needs something specific then they _know_ > >> they need something else and can easily set that variable either through > >> a > >> -D argument, through ccmake or through the CMake-GUI application. My > >> opinion is that this code should just be removed and that is one less bit > >> of code you have to deal with and maintain. > >> > >> If we are building HDF5 then I consider that a different use case than > >> downloading the prebuilt HDF5 libraries. If a user is downloading the > >> HDF5 > >> packages you may have different installation rules where you can have all > >> the grouped packages that put stuff in "HDFGroup/HDF5-1.8.13/" and such. > >> But if I have the technical knowledge to build HDF5 I most likely know > >> where I want to put it. And If this is my first go around at building and > >> installing HDF5 for development then when I go to install HDF5 and it > >> throws an error about permissions then as a user I'd probably search and > >> ask on the forums. I would rather field a few people asking what went > >> wrong > >> with their install and the easy answer is to set the CMAKE_INSTALL_PREFIX > >> than have a LOT of developers trying to figure out why the defaults are > >> not > >> in standard location for their platform (at least by default). I think > >> this > >> goes to the POLA > >> (http://www.ibm.com/developerworks/web/library/us-cranky10/index.html) of > >> using HDF5 (at least with CMake). I am expecting the default install to > >> go > >> to a certain location based on my use of other software frameworks. > >> > >> thoughts? > >> Mike Jackson > >> > >> On Apr 22, 2014, at 10:30 AM, Allen Byrne <[email protected]> wrote: > >>> Looking at CMake source for this, CMakeGenericSystem.cmake; > >>> > >>> # Choose a default install prefix for this platform. > >>> if(CMAKE_HOST_UNIX) > >>> > >>> set(CMAKE_INSTALL_PREFIX "/usr/local" > >>> > >>> CACHE PATH "Install path prefix, prepended onto install directories.") > >>> > >>> else() > >>> > >>> GetDefaultWindowsPrefixBase(CMAKE_GENERIC_PROGRAM_FILES) > >>> set(CMAKE_INSTALL_PREFIX > >>> > >>> "${CMAKE_GENERIC_PROGRAM_FILES}/${PROJECT_NAME}" > >>> CACHE PATH "Install path prefix, prepended onto install directories.") > >>> > >>> set(CMAKE_GENERIC_PROGRAM_FILES) > >>> > >>> endif() > >>> > >>> So maybe I need to fix HDF CMakeLists to just append the HDF folder: > >>> > >>> #----------------------------------------------------------------------- > >>> -- > >>> ---- # Set Install folder value > >>> #----------------------------------------------------------------------- > >>> -- > >>> ---- if (CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT) > >>> > >>> if (CMAKE_HOST_UNIX) > >>> > >>> set (CMAKE_INSTALL_PREFIX > >>> > >>> "${CMAKE_INSTALL_PREFIX}/HDF_Group/${HDF5_PACKAGE_NAME}/${HDF5_PACKAGE_V > >>> ER > >>> SION}"> > >>> > >>> CACHE PATH "Install path prefix, prepended onto install > >>> directories." > >>> > >>> FORCE) > >>> > >>> else (CMAKE_HOST_UNIX) > >>> > >>> GetDefaultWindowsPrefixBase(CMAKE_GENERIC_PROGRAM_FILES) > >>> set (CMAKE_INSTALL_PREFIX > >>> > >>> "${CMAKE_GENERIC_PROGRAM_FILES}/HDF_Group/${HDF5_PACKAGE_NAME}/${HDF > >>> 5 > >>> _PACKAGE_VERSION}" CACHE PATH "Install path prefix, prepended onto > >>> install directories."> > >>> > >>> FORCE) > >>> > >>> set (CMAKE_GENERIC_PROGRAM_FILES) > >>> > >>> endif (CMAKE_HOST_UNIX) > >>> > >>> endif (CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT) > >>> > >>> > >>> Therefore unless the user sets CMAKE_INSTALL_PREFIX, the HDF default on > >>> unix would be: > >>> > >>> /usr/local/HDF_Group/HDF5/1.8.13. > >>> > >>> Comments? > >>> > >>> Allen > >>> > >>> On Tuesday, April 22, 2014 09:45:27 AM Michael Jackson wrote: > >>>> I agree that we can not please everyone but some defaults are just > >>>> "better" > >>>> than others. For UNIX systems I think it is pretty "rare" or at least > >>>> non-standard to place installed products at the "/" level so having > >>>> /HDFGroup goes against this "norm" that most developers are expecting. > >>>> > >>>> I don't see a problem with setting the CMAKE_INSTALL_PREFIX on the > >>>> first > >>>> run (or any subsequent run) of CMake to the users default. > >>>> > >>>> cmake -DCMAKE_INSTALL_PREFIX=/Some/Path/To/HDF5 ../ > >>>> > >>>> isn't really any different than a ./configure --install …. line so > >>>> lets > >>>> just leave it as the CMake default value of /usr/local/ for Unix > >>>> systems. > >>>> > >>>> Thanks for the help > >>>> Mike Jackson > >>>> > >>>> On Apr 22, 2014, at 9:24 AM, Allen Byrne <[email protected]> wrote: > >>>>> Mike, > >>>>> > >>>>> I hope to get Frameworks support working some time soon, but I can > >>>>> > >>>>> understand your point. > >>>>> > >>>>> The trouble with this is that no one is happy. I had the default and > >>>>> someone complained so I tried a HDF default. > >>>>> > >>>>> I will just go with the default CMake one and leave > >>>>> CMAKE_INSTALL_PREFIX > >>>>> alone. > >>>>> > >>>>> Allen > >>>>> > >>>>> On Tuesday, April 22, 2014 08:47:37 AM Michael Jackson wrote: > >>>>>> I just tried the pre1 and the CMAKE_INSTALL_PREFIX is by default set > >>>>>> to > >>>>>> /HDF_Group/HDF5/1.8.13 which is pretty non standard for OS X. I am > >>>>>> not > >>>>>> sure > >>>>>> what the intent was but maybe leaving the default of /usr/local/ is > >>>>>> the > >>>>>> better choice. /Frameworks _might_ be appropriate if frameworks were > >>>>>> actually being built but my vote would be to just leave it as the > >>>>>> CMake > >>>>>> default value. > >>>>>> > >>>>>> Thoughts? > >>>>>> --- > >>>>>> Mike Jackson www.bluequartz.net > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Hdf-forum is for HDF software users discussion. > >>>>>> [email protected] > >>>>>> http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgr > >>>>>> ou > >>>>>> p. > >>>>>> org > >>>> > >>>> _______________________________________________ > >>>> Hdf-forum is for HDF software users discussion. > >>>> [email protected] > >>>> http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgrou > >>>> p. > >>>> org > >> > >> _______________________________________________ > >> Hdf-forum is for HDF software users discussion. > >> [email protected] > >> http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup. > >> org> > > _______________________________________________ > > Hdf-forum is for HDF software users discussion. > > [email protected] > > http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.o > > rg > _______________________________________________ > Hdf-forum is for HDF software users discussion. > [email protected] > http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org _______________________________________________ Hdf-forum is for HDF software users discussion. [email protected] http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org
