As suggested in https://github.com/NixOS/nixpkgs/pull/39416#discussion_r183845745
the versioning attributes in `lib` should be consistent to
`nixos/version` which implicates the following changes:
* `lib.trivial.version` -> `lib.trivial.release`
* `lib.trivial.suffix` -> `lib.trivial.versionSuffix`
* `lib.nixpkgsVersion` -> `lib.version`
As `lib.nixpkgsVersion` is referenced several times in `NixOS/nixpkgs`,
`NixOS/nix` and probably several user's setups. As the rename will cause
a notable impact it's better to keep `lib.nixpkgsVersion` as alias with
a warning yielded by `builtins.trace`.
* trying to build emscriptenPackages not all fail
* reading the console.log it turns out python executable is not in place and that is why emconfigure didnt work
* backup commit
* much more targets are compiling now
* added common revisioning
* revision bump to 1.37.36 (not tested)
* fixed xmllint
* forcing unit testing, will implement the tests after i get home
* json_c test working
* added tests
* tiny fixes
* added documentation
Improve beam docs:
* correct spelling
* update per pandoc changes
* capitalize titles
* capitalize BEAM throughout and use "the BEAM" when referring to the virtual machine.
* tweak grammar and phrasing
* reformat build-tools-rebar3 section
* add more links
* re-wrap <para>s
Also update <programlisting>s
* normalize whitespace
* don't double quote homepage
* use $ in all shell snippets
What I missed when I began using Nix and NixOS was a clear overview of
how packages, channels, Hydra, the master branch and updates to channels
relate to each other.
I've noticed I am not the only one, given the amount of times these
questions pop up.
For now I propose to include this in the Nixpkgs manual, since this
seems to be the best fit. However, I think it would be good to include
this in either a new manual, i.e., a user manual, or an 'official'
tutorial.
There's no change in content except for amending the title of the
section to mention "frameworks", as e.g. I don't consider Qt a language,
and it's likely there will be more of similar cases in future.
To be certain, I checked diff of the generated HTMLs.
Editing Docbook is no fun, IMHO, so I'd rather store the Haskell
documentation in Markdown format and use Pandoc to convert that into
Docbook as part of the build process.
