non standard header file location

[sjmackenzie]

Problem: header files are spread out all over the place making it harder to wrap the program

Solution: put all public API header files in an include directory.

Please reference libgit2 for an example: https://github.com/libgit2/libgit2/tree/master/include

[zjkmxy]

New commit adds an install command, allowing to install all header files into /usr/local/include/ndn-lite. You can try to run make install in the build folder.

[sjmackenzie]

Most linux systems have subtle differences in where they install artefacts. The assumption of using /usr/local/include/ndn-lite is a bit adventurous. For example when I run make install I get:

Install the project...
-- Install configuration: "Release"
-- Installing: /var/empty/local/include/ndn-lite/ndn-lite/ndn-lite
CMake Error at cmake_install.cmake:41 (file):
  file INSTALL cannot make directory
  "/var/empty/local/include/ndn-lite/ndn-lite/ndn-lite": No such file or
  directory

So a way around this is to issue a command similar to this cmake -DCMAKE_BUILD_TYPE=Release .. -DCMAKE_INSTALL_PREFIX=$out which allows one to control where the user wishes the output to be.

Though, and here are the problems:

• The install command only copies the headers and not the artefacts into the DCMAKE_INSTALL_PREFIX defined directory.
• Keep in mind that binary artefacts should be installed in $out/lib.
• Executables (i.e. unittests) should be installed in $out/bin.
• Lastly, it's good form to have a single top level .h file which exposes needed API. This makes it very clear to the user what the entry point is.

Expected behaviour

$out
├── bin
│     └── unittest
├── include
│     ├── ndn-lite
│     │   └── *.h
│     └── ndn-lite.h
└── lib
      └── ndn-lite.a

Actual behaviour

$out
└── include
    └── ndn-lite
        ├── adaptation
        │   └── adaptation
        │        └── *.h
        ├── ndn-lite
        │   └── ndn-lite
        │       ├── app-support
        │       ├── encode
        │       ├── face
        │       ├── forwarder
        │       ├── security
        │       └── util
        │           └── *.h
        └── ndn-lite.h

[zjkmxy]

Well, NDN-Lite is designed for constrained devices, not for linux. It's not designed to be installed as a library. That's why we made it into a static library and didn't provide any install function before you ask.
I can do what you want, but I think ndn-cxx and NFD is more suitable if you want to build a system on Linux PC.
About the top-level header, actually at the beginning I did exact as you suggested, but soon I find that the folder "adaptation" is confusing. Given that I cannot move it into ndn-lite repository, I choose to create another "ndn-lite" folder to wrap it up.

[sjmackenzie]

Understood, the consumer of this software will need to point at your artefact directory and can easily link to the software. What I just described is standard POSIX behaviour (please reference the name of this repository). In specific, I didn't really ask for an install command, just to correctly format the artefacts in standard POSIX fashion which'll be used for every embedded project that uses this software.
ndn-cxx and NFD are almost unusable, creating bindings for ndn-cxx is not easy at all hence it's better to use this software. Helping mold and refine the software keeps programmers in touch with the real world where it'll actually be used to solve real world problems.
As NDN is very compatible for IoT stuff, I'm also targeting embedded stuff so it makes sense to use this code.

[sjmackenzie]

My personal opinion: reduce all these repositories into one repository namely ndn-lite. Everyone will be using a static library anyway. So structure the artefacts in standard POSIX fashion and even embedded projects will thank you for it. It helps with running automatic binding generators over the include directory and when it comes to linking we just point at the lib/ndn-lite.a file. For those that just use C the same holds true except there is no binding generation step.

Loosely speaking: all the adaptation directories should be merged and essentially becomes a monolith "linux kernel" of sorts, in that it supports all the different hardware all from one repository. If you're targeting really constrained devices then you'd need to work on CMake magic to build things for the different platforms, but quite likely this is an optimization you shouldn't need.

The consuming project tells cmake to generate a nordic sdk, or x target and cmake does it. They then link to the generated ndn-lite.a output. Likely you should rename it accordingly.

Maybe ndn-lite.a could support all hardware programmed for it, and if you want a specialization then cmake generates (for example) ndn-lite-over-nordic-sdk.a or ndn-lite-over-riot.a.

Keep in mind that many devices are shrinking to the point that it's convenient to just install linux, indeed most "embedded" systems support linux out the box, i.e. your watch, sniper rifle etc. So the very first, most important "adaption" layer should be a linux adaption layer, likely ndn-lite.a should be defaulted with this. Given linux's huge iot prevalence.

Systems like RIOT accept that development takes place on linux & macos, meaning it makes sense ease developers lives. Why not go a step further and design as part of the ndn-lite architecture, via an adaption layer, to have first class support for general purpose kernels.

So likely an artefact directory similar to this (given that all repos are reduced to one repo) might work quite well, given there are different target platforms.

$out
├── bin
│     └── unittest
├── include
│     ├── ndn-lite
│     │   └── *.h
│     ├── ndn-lite-over-nordic-sdk
│     │   └── *.h
│     ├── ndn-lite-over-riot
│     │   └── *.h
│     └── ndn-lite.h
│     └── ndn-lite-over-nordic-sdk.h
│     └── ndn-lite-over-riot.h
└── lib
      ├── ndn-lite.a
      ├── ndn-lite-over-nodic-sdk.a
      └── ndn-lite-over-riot.a

This approach allows folks to develop/test on their linux || macos system then when it comes time to deploy their make files can pull in the needed target static lib. It also opens up an opportunity to deploy applications on tiny hardware devices that run linux.

Please keep in mind, at no point do I mean this library gets installed as a linux distribution package. Although it could easily be, if needed, given the POSIX layout which is equally suitable to be included as a developer dependency for an ad hoc IoT application.

[zjkmxy]

Thank you for your precious suggestions. I discussed with other members. We agree that it's a great idea but not an urgent thing to do, because currently we have no other customers, and this package still has a long way to be pushed in front of customers.
I'm sorry about this. Please tell me if you need any other help.

[sjmackenzie]

Thank you for your time.