Add documentation on how the client can include Nain4 in their project #10
Conversation
gonzaponte
changed the title
|
Does this depend on #11? |
|
It does. In the meantime, option 1 can be used if the user replaces the URL with one that points to my repo and the tag to my branch. Similarly, the other two options can be used if the client's clone of nain4 points to my branch. |
|
In that case, let's just merge, so that people can try it out without having to change anything else later on, besides the tag. Can you prepare this for use with tag |
|
Just to be clear, as it stands it will work as soon as we merge #11. Is up to the client to decide whether to use a tag, a commit hash or origin/master. Do you want to set |
|
Ah, sorry, I got confused again about which of #10/#11 we're in. I'll merge #11, and tag it with We don't need to merge the #10 in any hurry, because I can publish the docs without merging, so we can iterate on the docs more freely. |
|
With #13 merged, we should include the source code from the tests in these docs, and merge the docs source. Remember, the docs at https://jacg.github.io/nain4/ are published independently of There is also the question of how to mitigate the need to bump tags manually in #13's tests and these docs. |
|
Tag I don't really understand the |
I don't understand the question. v0.0.1 is valid, but I don't know what you are referring to.
IIUC, if you don't write |
We haven't merged anything that would require adding a new tag, and using it in the tests and docs.
OK, but I would discourage using branch names: people should stick to immutable things like commit hashes (very immutable, very inconvenient, more fine-grained) and tags (not guaranteed to be immutable, but almost; convenient; less fine-grained control). Then there's no guarantee that the remote will be called In summary, we're happy for the |
Nothing too relevant, I would say.
The documentation suggests using a tag. The option of using a branch is mentioned but discouraged for the same reasons you lay down here.
This is how I understand it.
I don't have a strong feeling about this. The main reason that is there is because it was suggested by the cmake documentation, which favored being up to date with the remote tags. We are free to choose our own path. |
|
After stepping back to read it in context, I think it's spot on. |
|
I literally had my fingers on the keyboard to push the merge, when these last commits arrived? Is it ready now, or do you want to do any more? |
|
I'm done |
Describes how to include nain4 in client projects using CMake.