Closed dbu closed 2 years ago
Hi @dbu !
That doesn't seem quite right, the alpine
and arch
packages don't explicitly build the docs and yet the install succeeds. Could you share some details about your platform, and possibly some logs?
Also, we should probably fix this by making rst-docs
a requirement to install
hi guillaume :wave:
this build failed during make install
https://github.com/FriendsOfSymfony/FOSHttpCache/runs/4583897941?check_suite_focus=true
then i pushed this change https://github.com/FriendsOfSymfony/FOSHttpCache/pull/500/commits/f18e76858ccfadb881270a1820ca868ca6bc39f9 and got further (builds are still red for that one, but because of the next step, the installation works)
ideally the docs are optional, building them on a ci machine is not useful. i did not study the makefile, not sure if this is platform dependent, or if building the docs has a side effect on ubuntu that is required for the install to work.
If you build from a release archive you don't need python docutils since manuals were already bootstrapped. In general anything already bootstrapped cuts down the number of dependencies when building from a release archive (python docutils, autoconf, automake, autoheader, aclocal, libtool, etc).
If you build from a git clone, it's your responsibility to build the docs.
Of course if you build from a release archive and the readme tells you to run the bootstrap script, it becomes pointless as you end up needing those dependencies anyway.
@Dridi not sure if that comment was for me or for the maintainers
i am downloading the release archive in that github action.
the readme does tell to run ./bootstrap
. there is no ./configure
before running bootstrap, and also no Makefile. so to build the library, i seem to need those. does the release include the compiled modules and a different way to install them?
@Dridi not sure if that comment was for me or for the maintainers
Maintainers.
the readme does tell to run
./bootstrap
.
My point.
there is no
./configure
before running bootstrap, and also no Makefile
Curious, there should.
Following your links I found this:
https://github.com/varnish/varnish-modules/archive/refs/tags/${VARNISH_MODULES_VERSION}.tar.gz
This is a source archive generated by github, not an actual release archive bootstrapped by a maintainer.
This on the other hand is a proper release archive: https://github.com/varnish/varnish-modules/releases/download/0.19.0/varnish-modules-0.19.0.tar.gz
But 0.19.0 seems to be the only github-only release with a proper release archive available as a download asset for the release tag, so I'm not surprised you'd need to grab a source archive instead of a release archive.
ah, then i see what you mean.
would be neat to have a "proper release". should be possible to automate that in a github action (but i don't have time to look into it).
meanwhile, i can work with it by building the docs so that make install
succeeds.
yeah, I created a dist tarball for 0.19.0
and will do so for future versions, but I didn't take the time to do it for past releases. I can create them for older (but still supported) releases if you want, just open a ticket and I'll be on it
@dbu , would you care repurposing this PR to explain the two cases (dist tarball vs git/source tarball)? Otherwise I'll be happy to do it
cheers!
i updated the readme. its not a big hassle for me to make the doc to build older versions, no need to re-create those releases imho.
installing the modules fails when the doc has not been built