I could argue that the autoconf "make install" just dumping in /usr/local is a "Bad idea" all around. How many times have we all come across libraries that either don't groups their includes or have really nice generic header files like "version.h" which over writes other library's version.h file?
So I tried "make package" and I end up with some "oddities" with the package. It has the full path in the archive (CMAKE_INSTALL_PREFIX=/tmp/hdf5-1.8.13) when I decompress it. In the CMakeInstallation.cmake file at line 298 I set the variable to "FALSE" and I get a more reasonable archive (tar.gz) created. I guess it really depends on what you are trying to accomplish with the packaging. I think for the development libraries just having a tar.gz is OK. The "Drag-n-Drop" .dmg file may really be over-kill (and confusing) for the end developer. Either that or you can go with a full blown installer that allows the developer to install anywhere they want with the proper corrections to the "install_name" and all that. Just not sure how much time you have to put into this. Mike Jackson On Apr 22, 2014, at 11:45 AM, Allen Byrne <[email protected]> wrote: > So the original problem is that 'make install' will use the default > /usr/local > not /usr/local/hdf5 for the bin,include,lib, and share folders. > > CPack had already manipulated the install locations (except for unix where it > did not prepend /usr/local). > > So there are two problems, the default unix without a package folder and > cpack > not using CMAKE_INSTALL_PREFIX. > > Allen > > On Tuesday, April 22, 2014 10:18:41 AM Allen Byrne wrote: >> 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}/${H >>>>>> DF >>>>>> 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.hdf >>>>>>>>> gr >>>>>>>>> ou >>>>>>>>> p. >>>>>>>>> org >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>> .o >>>> rg >>> >>> _______________________________________________ >>> 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 _______________________________________________ Hdf-forum is for HDF software users discussion. [email protected] http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org
