Nana install misses include files

[steveking-gh]

Using CMake, gcc 5.3 and Fedora 23 64-bit:
After setting CMAKE_INSTALL_PREFIX to specify the installation directory, the build succeeds but the installation directory contains only libnana.a. The install directory should also contain the required include files.

[cnjinhao]

Thank you for your suggestion.

[qPCR4vir]

Hi,
it is true that this could make things easier for some people and we need to include it.
But I want you to think about the following: this encourages people to have part of the nana source code not only duplicated somewhere in disk, but also outside the control version system (outside the git repository).
I had myself a bad experience with that. I used, and eventually modified orange, but not under git. When I wanted to publish and I wanted to contribute back my changes I found very difficult to track my own work, without my own commits and history of changes. Worst, the original repo evolved and I had a hard time to organize a patch. When finally I made a PR it was to late and nobody cares about it.
This have to be an option (maybe default?) because I don't need that duplication. Maybe there is a trivial way to indicate where are the includes that people need to use?

[cnjinhao]

It is good to have an option to duplicate includes(IMO,disabled default).

[Arrfaylloordss]

Installation of include files (usually headers) is standard procedure for external libraries. Include files can contain platform dependent or feature-support modifications made during configuration step. And they are part of a fixed release distribution. If it is aim to develop the library itself, then it's much better do this in a separate source directory of library directly. Thus no duplication of code and unpredictable mixing of versions will occur.

[cnjinhao]

A release distribution is provided for every release, you can download it at homepage of nanapro.org. The github is a repo for developing library, it is a bit different with the release distribution.

[Arrfaylloordss]

But who does use install target of CMAKE during a library development? Is there any purpose? From the topic starter post I thought that the problem is about CMAKE installation script.
Sorry for bothering in case of misunderstanding.

[qPCR4vir]

Hi,
your observation is anyway very valuable. Now we know that we need to do it better. Any idea is welcome. I have the problem that I'm using cmake but with CLion. CLion take control of many things, and invalidate some of the variables and commands in my CMakeList.txt - changing CMAKE_INSTALL_PREFIX have no effect. And yes, the build dir is somewhere and I need to "install" the results - but my install dont works ...it is set in the GUI. I must test all that in travis, which is not very convenient.
I think I don't understand completely what do you mean with:

they are part of a fixed release distribution.

I use to change nana directly under git (switching branch as needed). Any other variant is very complicate for me.
BTW, what version are you testing?
ah.. right now we don't change any *.h file with cmake. How to make this compatible with people that don't use cmake? .. you need to use the same option during the link to your code that you used to build nana. It is a problem, we know, and we try to solve it. Again, suggestions are welcome.
Thank!

[Pr0curo]

Hi Everyone,

I cannot understand why someone would change the installed header files, even though they have to be overwritten after making changes to the library. why not simply change the files in the git repository and compile/install again, so the changes (library and headerfiles) will get copied in the right folder. Plus this way all files are updated when a change was introduced. I also would advise against making it an option, there are already to many options to chose from in my opinion.

Thus I think the suggested way from steve6390 is the right way.

best regards,
Pr0curo

[qPCR4vir]

Hi...
well its seems that you are right. (maybe I can hardly think about nana being external, though I had it in c:/prog/ExtLib/nana ! ).

I just don't have sufficient experience and no way to test:
Why is not working as we expect?
Could you change the line

install(DIRECTORY ${CMAKE_SOURCE_DIR}/include/nana DESTINATION include)

which is there from a long time with this:

install(DIRECTORY ${NANA_INCLUDE_DIR}/nana DESTINATION include)

or something similar?

I cannot understand why someone would change the installed header files

well, when I'm browsing my user code and I hit "go to definition" it will go to the installed includes not to the original files. But if this is a problem I think I will manage that somehow else.

[Pr0curo]

Hi,

first, after reading my last post, it sounds a little rude. Sorry for that, it was not intended (english is my second language).

second, I might found a solution, but as my experience with cmake is limited I'm not sure whether this is the right way or not. The solution is based on Windows 10, but should work everywhere.

first i created a file nana-config.cmakein c:/program files (x86)/nana/with the following content:

set(nana_INCLUDE_DIRS ${CMAKE_CURRENT_LIST_DIR}/include/)
set(nana_LIBRARY ${CMAKE_CURRENT_LIST_DIR}/lib/libnana.a)

and then in your own projects cmake-file you can add:

#searching for nana
find_package(nana REQUIRED)

now cmake should know about nana and you can use the variables nana_INCLUDE_DIRS and nana_LIBRARYto add nana to your include paths and link the nana library.

this way it is possible to use nana without any hardcoded paths. if someone knowledgable can aprove this way, I'd love to submit the change as a patch.

[qPCR4vir]

Hallo !
Please... is this correct? https://travis-ci.org/qPCR4vir/nana-demo/jobs/141378043
Well, maybe in the "installed" headers we will need to include a fully configured new header with all the options, to avoid duplication or erroneous setting......

The find_packagewill be the next goal.