Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Installs headers that have generic names #105

Open
ryandesign opened this issue Oct 24, 2018 · 1 comment
Open

Installs headers that have generic names #105

ryandesign opened this issue Oct 24, 2018 · 1 comment

Comments

@ryandesign
Copy link

libminc installs a number of headers into the include directory of the installation prefix that have generic names, such as ParseArgv.h, read_file_names.h, restructure.h, and time_stamp.h. These files might collide with files installed by another package, or might cause build failures of other projects that have project-local include files of those names, if those projects don't use the right order of -I flags (which is a very common problem) resulting in the -I flag for the system include directory appearing before the -I flag for the project's own include files.

It would be better if the names of all of the headers that get installed directly into the include directory were changed to something that one could reasonably expect to be unique to libminc, or if they were installed into a subdirectory of the include directory instead (like you already do for the volume_io files).

These headers aren't installed if I set -DLIBMINC_INSTALL_NO_DEVELOPMENT=ON, but then most of the headers aren't installed, including minc.h and minc2.h; those sound important, which makes me think I should not use this option. I couldn't find an explanation of the LIBMINC_INSTALL_NO_DEVELOPMENT option, so I don't know who is expected to use it, under what circumstances, but the fact that it is not on by default suggests to me that it should not usually be used.

@gdevenyi
Copy link
Contributor

Most of the minc tools have always been installed in their own private prefix, rather than the main system so this hasn't been an issue.

This is a good observation though, perhaps we need a mass prefix rename to prevent collisions. This is harder than you might think considering the size of minc-toolkit though....

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants