doxyrest: init at master #98449
doxyrest: init at master #98449
Conversation
HaoZeke
force-pushed
the
initDoxyrest
branch
from
27cf7aa
to
0aa18f3
Compare
| # Somehow fetchFromGithub was ignoring submodules | ||
| src = fetchgit { | ||
| url = "https://github.com/vovkos/doxyrest_b"; | ||
| rev = "3500bc0101c5ebe4921d8cca49b42e209e761971"; |
There was a problem hiding this comment.
There was a problem hiding this comment.
It's much too old. A lot of fixes have been put in master since then.
There was a problem hiding this comment.
To be clearer, the current setup corresponds to https://github.com/vovkos/doxyrest/releases/tag/doxyrest-2.1.0
It's just that the build repo doesn't release the same way (since it is updated with each push).
| fetchSubmodules = true; | ||
| }; | ||
|
|
||
| nativeBuildInputs = [ expat lua5 ragelDev which cmake ]; |
There was a problem hiding this comment.
What does expat and lua5 are used for? I'm asking because I'm rather sure they belong to buildInputs.
There was a problem hiding this comment.
I'm not sure, lua is used for the configuration of the doxyrest binary, and expat is also used by the binary to read in XML files. Should they then belong in buildInputs?
| hardeningDisable = [ "format" ]; | ||
|
|
||
| meta = with stdenv.lib; { | ||
| description = "A compiler from Doxygen XML to reStructuredText"; |
There was a problem hiding this comment.
Upstream says:
This is a repository bundle (Doxyrest + AXL). With this bundle you can conveniently build Doxyrest and all the libraries it depends on -- in correct order and from the single source tree.
Sounds like they try to solve a problem Nix already does.
There was a problem hiding this comment.
It's actually the build repo for https://github.com/vovkos/doxyrest
I guess in a sense it might be better to add a package for each sub-module and then finally open one for this package, but it seemed like an over-exuberant response at the moment, since I can find no (obvious) other use-cases for the submodules.
There was a problem hiding this comment.
I see. What happens when you try to build from https://github.com/vovkos/doxyrest directly?
There was a problem hiding this comment.
Nothing much, except it would require building each submodule at the commit referenced in the build directory. I could probably set that up over the weekend, shouldn't be hard, they seem to be cmake build stuff.
There was a problem hiding this comment.
The fact they "recommend" building with a totally separate repo might be suitable for users of other distros, but not for NixOS IMO. I think you should create derivations for each such submodule dependency, and try to tell the builder to use the "system"'s dependencies. See similar discussion at #91930 (comment) .
There was a problem hiding this comment.
That kind of defeats the purpose of having fetchSubmodules as an option for fetchgit then, would it not?
There was a problem hiding this comment.
I do not believe it makes sense to manually track the build repo (by checking which commits the submodules are pinned to) every time, just because "it feels more Nix like". There are reasons why we have support for fetchSubmodules and this is a good example IMO.
There was a problem hiding this comment.
I'm not against the usage of fetchSubmodules. I just think that the submodules should be exposed as Nix derivations, because yes, someone may find use to them in the future, and if they produce shared libraries they should be shared in the Nix Store.
by checking which commits the submodules are pinned to) every time
You could write an updateScript, that will fetch the matching commits of these submodules, given a rev of the main repo, and then write a json / Nix file that will be used by the expression of https://github.com/vovkos/doxyrest .
| meta = with stdenv.lib; { | ||
| description = "A compiler from Doxygen XML to reStructuredText"; | ||
| longDescription = | ||
| "A compiler from Doxygen XML to reStructuredText -- hence, the name. It parses XML databases generated by Doxygen and produces reStructuredText for the Python documentation generator Sphinx."; |
There was a problem hiding this comment.
Again, upstream says differently.
There was a problem hiding this comment.
That's because the output of this build is the doxyrest binary, which is what we need, and so the description is from this: https://github.com/vovkos/doxyrest
The build repo referenced is just to streamline building doxyrest.
It basically parses Doxygen XML files to RST. |
| # otherwise "cc1: error: -Wformat-security ignored without -Wformat [-Werror=format-security]" | ||
| hardeningDisable = [ "format" ]; | ||
|
|
||
| meta = with stdenv.lib; { |
There was a problem hiding this comment.
| meta = with stdenv.lib; { | |
| meta = with lib; { |
| @@ -10957,6 +10957,8 @@ in | |||
| inherit (darwin.apple_sdk.frameworks) CoreServices; | |||
| }; | |||
|
|
|||
| doxyrest = callPackage ../development/tools/documentation/doxyrest {}; | |||
There was a problem hiding this comment.
| doxyrest = callPackage ../development/tools/documentation/doxyrest {}; | |
| doxyrest = callPackage ../development/tools/documentation/doxyrest { }; |
|
I marked this as stale due to inactivity. → More info |
stale
bot
added
the
2.status: stale
|
@HaoZeke would you like to revisit this package init with the latest release from upstream (2.1.2) ? And resolve the merge conflicts? |
stale
bot
removed
the
2.status: stale
Absolutely, sorry for letting this go stale. |
|
I marked this as stale due to inactivity. → More info |
stale
bot
added
the
2.status: stale
|
Closing due to merge conflict and no response from OP. |
Motivation for this change
Initialized a new package.
Things done
sandboxinnix.confon non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"./result/bin/)nix path-info -Sbefore and after)