> Not really. I developed the man part first and then it seemed natural to do
> the html docs separately and then ended up wondering about the same very
> thing. A potential reason to not combine is the ability to just take the docs
> tarball and unpack into http://ftp.rpm.org/api/ with no further processing.
> But for that, the remove step should be removed (these get cleaned up by
> 'make clean' anyhow).
Ah sure, OK then, nevermind, it's fine this way, we wouldn't be saving that
much code if it were just one target, anyway.
> The tar is only picking stuff up from the binary tree, so chances of having
> something extra is relatively low. I had a version that did the tarball from
> docs/man/CMakeLists.txt where the static list is available but ran into other
> problems that made me move it all to the main cmake file... only to run into
> the same issue there in just slightly different form laughing So now that
> _that_ problem (path prefixes) is solved, it could indeed be done from there
> with the aid of the static list. I'll give it a go.
Heh, cool. But you're probably right, we just have to assume that the build
tree is "pristine" and not somebody's dumping area. In other words, that the
person making a release tarball actually knows what's in there and possibly
even creates a fresh build directory for that activity. So not a big deal by
any means. But sure, if you can easily move it to that other CMakeLists.txt
file, why not :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2467#issuecomment-1498631896
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/pull/2467/c1498631...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
