Use GNUInstallDirs for specifying default directories #140

SoapGentoo · 2017-05-25T10:32:08Z

Being able to change the default directories is important
for distros. Even more so with a consistent interface.
GNUInstallDirs is the only Kitware supported way to change
the defaults without downstream consumers of CMake
making up new and inconsistent options between each other.

Associated PR for the Gettext module: ooxi/CMake-Gettext#1

* Being able to change the default directories is important for distros. Even more so with a consistent interface. GNUInstallDirs is the only Kitware supported way to change the defaults without downstream consumers of CMake making up new and inconsistent options between each other.

* It is customary not to install README files in data directories but rather in DOCDIR.

* Different distros have compiled boost with different -std= options. Hardcoding this only wreaks massive havoc with parts of the ecosystem already using C++11.

ooxi · 2017-05-26T10:41:59Z

While I really like the patch I cannot merge as is, because of the following reasons:

b770ce9 changes too many unrelated options at once. I started a GitHub review with the issues
38a00e9 I'm not sure if I can omit hard coding C++98 since I need at least C++98 support but do not require newer versions. I get your point about libraries in a distribution compiled with another standard. Would it be possible to define C++98 iff no other standard is required?

Nevertheless thanks your contribution, I'd really like to support GNUInstallDirs! Are you planning on packaging Violetland on a distribution?

SoapGentoo · 2017-05-26T10:56:11Z

@ooxi

how do you mean you need "at least" C++98? Literally every compiler since 2003 supports C++98 and (below GCC 6) also runs in C++98 mode by default. Hardcoding the C++ standard causes issues for us on Gentoo, where Boost is compiled in C++14 mode. There is no need to explicitly request C++98 support. In fact, things are even worse on Windows: MSVC in general doesn't allow for changing the language standard, hence trying to enforce C++98 is imo futile. Just use the compiler default, and aim for a codebase that works with both C++98 and C++11 and everything will work fine.
I can split up the CMakeLists.txt changes, but imo a lot of that is generally pointless, as they change lines in close proximity which will make reverting impossible either way.

We have violetland packaged in Gentoo currently, but using GNUInstallDirs would not just help Gentoo, but all distributions, as its the only idiomatic way to specify the dirs.

ooxi · 2017-05-26T12:37:20Z

Thanks for your feedback. I will integrate support for GNUInstallDirs but with the possibility to overwrite.

SoapGentoo · 2017-05-26T13:00:00Z

@ooxi GNUInstallDir is perfectly overridable (that's the point of the GNU conventions). I recommend adding something along the lines of

if(WIN32)
	set(CMAKE_INSTALL_LOCALEDIR "mylocaledir" CACHE STRING "Windows locale dir")
	GNUInstallDirs_get_absolute_install_dir(CMAKE_INSTALL_FULL_LOCALEDIR CMAKE_INSTALL_LOCALEDIR)
endif(WIN32)

instead of making the inclusion of GNUInstallDir conditional. What would you like me to change?

ooxi · 2017-05-26T13:09:28Z

That's even better! Essentially cmake -DCMAKE_INSTALL_PREFIX=../dist .. should still work after this patch :-)

SoapGentoo · 2017-05-26T13:10:49Z

@ooxi also I dont see the Github review? Did you forget to click request changes maybe?

ooxi

Very good, would like to merge when resolved

ooxi · 2017-05-26T10:24:38Z

CMakeLists.txt

-CMAKE_MINIMUM_REQUIRED(VERSION 2.6.0 FATAL_ERROR)
-CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
-
+CMAKE_MINIMUM_REQUIRED(VERSION 2.8.12)


Why 2.8.12?

add_compile_options requires 2.8.12 and is the proper idiomatic way to add flags

Since the oldest supported Ubuntu version (14.04) ships with CMake 2.8.12 I agree bumping the version requirement to get add_compile_options is the right thing to do 👍

ooxi · 2017-05-26T10:27:10Z

CMakeLists.txt

 add_definitions(-DINSTALL_PREFIX="${CMAKE_INSTALL_PREFIX}")
-add_definitions(-DLOCALE_DIR="${LOCALEDIR}")
+add_definitions(-DLOCALE_DIR="${CMAKE_INSTALL_FULL_LOCALEDIR}")


If I understand the documentation of CMAKE_INSTALL_FULL_LOCALEDIR correctly this is always and absolute path. Therefore it's no longer possible to do a local build without system installation.

I would like to continue supporting LOCALE_INSTALL_DIR and only falling back to CMAKE_INSTALL_FULL_LOCALEDIR if undefined.

what do you mean by a "local" build? In the source tree? Not into a system dir?

By local build I mean into any directory, specifically a system dir (for example install relative to ../dist so the final executable and resources can be moved freely).

I agree that this is not an issue for distributions but for development it's extremely helpful

installing relative to ../dist is fine as is, the problem with the previous solution was that it is brittle: resources /= "../share/violetland"; assumes a rigid structure. What if the executable is installed as ../dist/violetland (without an intermediate bin/ dir) and the data files in ../dist/share/violetland? Then the old solution will break either way. With GNUInstallDir, you can install into ../dist, you just cannot relocate it once you have make installed it, which, while a bit of a pity, I still think is much more stable than relying on an implicit directory structure.

@ooxi ping?

ooxi · 2017-05-26T10:38:01Z

CMakeLists.txt

@@ -173,16 +166,15 @@ set(VIOLET_SOURCES
 # in boost 1.57 but Ubuntu before wily does not ship that version.
 #
 # @see https://svn.boost.org/trac/boost/ticket/6779
-set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++98")
+add_compile_options(-std=c++98)


Changing set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} XXX") to add_compile_options(XXX) should be done in a separate commit.

ooxi · 2017-05-26T10:38:30Z

CMakeLists.txt

-install(TARGETS violetland DESTINATION bin)
+add_definitions(-DDATA_INSTALL_DIR="${CMAKE_INSTALL_FULL_DATADIR}/violetland/")
+
+install(TARGETS violetland DESTINATION ${CMAKE_INSTALL_BINDIR})


Same as before, doesn't this demand a system installation?

CMAKE_INSTALL_BINDIR has nothing to do with a system installation, you can still install it in ~/my_test_dir

Sorry I misplaced my review comment: it was about setting DATA_INSTALL_DIR to CMAKE_INSTALL_FULL_DATADIR which would imply an absolute path, wouldn't it?

ooxi · 2017-05-26T13:12:11Z

@SoapGentoo you are correct I did not know you had to submit the review (never worked with reviews before). Thanks for your patience :-)

SoapGentoo · 2017-05-27T11:02:26Z

src/system/utility/FileUtility.cpp

@@ -40,21 +40,13 @@ violet::FileUtility* violet::FileUtility::ofUnix() {

 	/* Application binary
 	 */
-#ifndef INSTALL_PREFIX
-#define INSTALL_PREFIX "/usr/local";
-#endif //INSTALL_PREFIX
 	boost::filesystem::path application = INSTALL_PREFIX;


@ooxi I just noticed this too. By hardcoding the prefix into the source, your installation is never relocatable, because everything is relative to it. Hence, I would just settle for full paths unconditionally, given that it didnt work previously anyhow.

@ooxi Tell me how you'd like to proceed. I believe we should just use the GNUInstallDir solution, as the current solution is not relocatable either.

Normally the installation is relocatable since INSTALLATION_PREFIX etc. can be set to a relative path. I'm actually not sure on how to proceed :/

SoapGentoo added 3 commits May 25, 2017 12:43

Do not install README files in DATADIR

1a7735c

* It is customary not to install README files in data directories but rather in DOCDIR.

Do not hardcode C++98

38a00e9

* Different distros have compiled boost with different -std= options. Hardcoding this only wreaks massive havoc with parts of the ecosystem already using C++11.

SoapGentoo force-pushed the cmake-fixes branch from 26ba499 to 38a00e9 Compare May 25, 2017 10:43

ooxi reviewed May 26, 2017

View reviewed changes

ooxi mentioned this pull request May 27, 2017

Makefile should use add_compile_options #141

Open

SoapGentoo commented May 27, 2017

View reviewed changes

ooxi added this to the Release 0.6 milestone Dec 27, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Use GNUInstallDirs for specifying default directories #140

Use GNUInstallDirs for specifying default directories #140

SoapGentoo commented May 25, 2017 •

edited

ooxi commented May 26, 2017 •

edited

SoapGentoo commented May 26, 2017

ooxi commented May 26, 2017

SoapGentoo commented May 26, 2017

ooxi commented May 26, 2017

SoapGentoo commented May 26, 2017

ooxi left a comment

ooxi May 26, 2017

SoapGentoo May 26, 2017

ooxi May 27, 2017

ooxi May 26, 2017

SoapGentoo May 26, 2017

ooxi May 27, 2017

SoapGentoo May 27, 2017

SoapGentoo Jun 5, 2017

ooxi May 26, 2017

ooxi May 26, 2017

SoapGentoo May 26, 2017

ooxi May 27, 2017

ooxi commented May 26, 2017

SoapGentoo May 27, 2017

SoapGentoo Jun 5, 2017

ooxi Jun 5, 2017

Use GNUInstallDirs for specifying default directories #140

Are you sure you want to change the base?

Use GNUInstallDirs for specifying default directories #140

Conversation

SoapGentoo commented May 25, 2017 • edited

ooxi commented May 26, 2017 • edited

SoapGentoo commented May 26, 2017

ooxi commented May 26, 2017

SoapGentoo commented May 26, 2017

ooxi commented May 26, 2017

SoapGentoo commented May 26, 2017

ooxi left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ooxi commented May 26, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

SoapGentoo commented May 25, 2017 •

edited

ooxi commented May 26, 2017 •

edited