1.8.13 pre1 default CMAKE_INSTALL_PREFIX is non standard

Hdf-forum archives
1

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

2

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.
Hdf-forum@lists.hdfgroup.org
http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org

3

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 <byrn@hdfgroup.org> 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.
Hdf-forum@lists.hdfgroup.org
http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org

4

/usr/local

+1.

The only other sensible default of Un*x would be
/opt/something_or_other but /usr/local is what autoconf folks would
expect.

- Rhys

5

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_VERSION}"
      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}/${HDF5_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 <byrn@hdfgroup.org> 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.
>> Hdf-forum@lists.hdfgroup.org
>> http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.
>> org
_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@lists.hdfgroup.org
http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org

6

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 <byrn@hdfgroup.org> 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_VERSION}"
     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}/${HDF5_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 <byrn@hdfgroup.org> 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.
Hdf-forum@lists.hdfgroup.org
http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.
org

_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@lists.hdfgroup.org
http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org

7

+1 for /usr/local.

···

-----Original Message-----
From: Hdf-forum [mailto:hdf-forum-bounces@lists.hdfgroup.org] On Behalf Of Rhys Ulerich
Sent: Tuesday, April 22, 2014 9:00 AM
To: HDF Users Discussion List
Subject: Re: [Hdf-forum] 1.8.13 pre1 default CMAKE_INSTALL_PREFIX is non standard

/usr/local

+1.

The only other sensible default of Un*x would be /opt/something_or_other but /usr/local is what autoconf folks would expect.

- Rhys

_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@lists.hdfgroup.org
http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org

8

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 <byrn@hdfgroup.org> 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_VER
> 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}/${HDF5
> _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 <byrn@hdfgroup.org> 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.
>>>> Hdf-forum@lists.hdfgroup.org
>>>> http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgrou
>>>> p.
>>>> org
>>
>> _______________________________________________
>> Hdf-forum is for HDF software users discussion.
>> Hdf-forum@lists.hdfgroup.org
>> http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.
>> org
_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@lists.hdfgroup.org
http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org

9

I posted the wrong link for "POLA"

This is a better one
http://www.faqs.org/docs/artu/ch11s01.html

Mike Jackson

···

On Apr 22, 2014, at 10:43 AM, Michael Jackson <mike.jackson@bluequartz.net> 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 <byrn@hdfgroup.org> 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_VERSION}"
    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}/${HDF5_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 <byrn@hdfgroup.org> 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.
Hdf-forum@lists.hdfgroup.org
http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.
org

_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@lists.hdfgroup.org
http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org

10

FWIW, I agree with Mike here.

Cheers,

···

On Tue, 22 Apr 2014 10:43:11 -0400, Michael Jackson said:

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.

--
____________________________________________________________
Sean McBride, B. Eng sean@rogue-research.com
Rogue Research www.rogue-research.com
Mac Software Developer Montréal, Québec, Canada

11

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 <byrn@hdfgroup.org> 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 <byrn@hdfgroup.org> 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_VER
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}/${HDF5
    _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 <byrn@hdfgroup.org> 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.
Hdf-forum@lists.hdfgroup.org
http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgrou
p.
org

_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@lists.hdfgroup.org
http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.
org

_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@lists.hdfgroup.org
http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org

_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@lists.hdfgroup.org
http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org

12

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 <byrn@hdfgroup.org> 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 <byrn@hdfgroup.org> 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 <byrn@hdfgroup.org> 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.
>>>>>> Hdf-forum@lists.hdfgroup.org
>>>>>> http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgr
>>>>>> ou
>>>>>> p.
>>>>>> org
>>>>
>>>> _______________________________________________
>>>> Hdf-forum is for HDF software users discussion.
>>>> Hdf-forum@lists.hdfgroup.org
>>>> http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgrou
>>>> p.
>>>> org
>>
>> _______________________________________________
>> Hdf-forum is for HDF software users discussion.
>> Hdf-forum@lists.hdfgroup.org
>> http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.
>> >
> _______________________________________________
> Hdf-forum is for HDF software users discussion.
> Hdf-forum@lists.hdfgroup.org
> http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.o
> rg
_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@lists.hdfgroup.org
http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org

13

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 <byrn@hdfgroup.org> 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 <byrn@hdfgroup.org> 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 <byrn@hdfgroup.org> 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.
> >>>>>> Hdf-forum@lists.hdfgroup.org
> >>>>>> http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdf
> >>>>>> gr
> >>>>>> ou
> >>>>>> p.
> >>>>>> org
> >>>>
> >>>> _______________________________________________
> >>>> Hdf-forum is for HDF software users discussion.
> >>>> Hdf-forum@lists.hdfgroup.org
> >>>> http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgr
> >>>> ou
> >>>> p.
> >>>> org
> >>
> >> _______________________________________________
> >> Hdf-forum is for HDF software users discussion.
> >> Hdf-forum@lists.hdfgroup.org
> >> http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgrou
> >> p.
> >> >
> >
> > _______________________________________________
> > Hdf-forum is for HDF software users discussion.
> > Hdf-forum@lists.hdfgroup.org
> > http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup
> > .o
> > rg
>
> _______________________________________________
> Hdf-forum is for HDF software users discussion.
> Hdf-forum@lists.hdfgroup.org
> http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.o
> rg
_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@lists.hdfgroup.org
http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org

14

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 <byrn@hdfgroup.org> 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 <byrn@hdfgroup.org> 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 <byrn@hdfgroup.org> 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 <byrn@hdfgroup.org> 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.
Hdf-forum@lists.hdfgroup.org
http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdf
gr
ou
p.
org

_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@lists.hdfgroup.org
http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgr
ou
p.
org

_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@lists.hdfgroup.org
http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgrou
p.
>

_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@lists.hdfgroup.org
http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup
.o
rg

_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@lists.hdfgroup.org
http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.o
rg

_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@lists.hdfgroup.org
http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org

_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@lists.hdfgroup.org
http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org

15

Mike,

   On the Mac and linux - our binaries are built from the autotools.

   CMake/CPack is used to build the Windows binaries.

For 'User" CMake builds on all platforms, CPack will build tar.gz files with
HDF5 package structure. 'make install' will install into the defaults
(/usr/local on unix).
For 'User" CMake builds on the Mac (not our binaries) I'm working on
developing the framework bundle option. The "Drag-n-Drop" .dmg file is just
there and should be removed.

For the next pre-release, I have removed the CMAKE_INSTALL_PREFIX block
completely and changed the Mac tar.gz CPack generation to mirror the linux
process.

Unfortunately, I don't have an answer to the "make install" dumping into
/usr/local.

Allen

···

On Tuesday, April 22, 2014 02:09:30 PM Michael Jackson wrote:

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 <byrn@hdfgroup.org> 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 <byrn@hdfgroup.org> 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 <byrn@hdfgroup.org> 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_PACKAG
>>>>>> E
>>>>>> _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 <byrn@hdfgroup.org> 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
>>>>>>>>>