Hi, Le lundi 17 février 2025 à 10:07 +0100, Julien Plissonneau Duquène a écrit : > Le 2025-02-16 21:03, Julien Puydt a écrit : > > > > - the previous version used %%VERSION_NUM%% in only three places, > > the > > new one uses it more, so it broke my previous hack -- ; > > As a matter of best practices, this should probably be defined in a > single place and not "hardcoded" multiple times with templating.
Yes. Most upstream have little clue on what a best practice is, and need to be explained at length. That's part of the job of a DD... > > - there are other things than the substitutions done by dune when > > compiling the package, which do not break the build, but will break > > some depending packages later on with strange and misleading > > errors. > > Do you mean here that using the "official" tbz source tarballs for > builds outside of a git tree will result in these errors? If so, > that's a serious upstream build tool issue IMO. No, I mean the build tool takes the git repo with the .git/ directory, and gives a tarball without .git/ where substitutions have been made (those can be recognized because they look like %%FOO_BAR%%) *and* some code added in various places (those can't be recognized beforehand). Their .tbz is working nicely -- but it isn't source anymore! > > As mentioned somewhere in the thread I proposed to dune upstream a > > simple mechanism to bypass this git reliance issue, which will make > > packaging much cleaner. > > That's probably the way to go here. I would also suggest modifying > dune-release so the git release tags end up with the substitutions > already applied, to make it possible to simply export them and build > them outside of a git tree. I think the way to go is the one I proposed in my upstream bug report ( https://github.com/ocaml/dune/issues/11484 ) and which Stéphane Glondu proposed a PR for ( https://github.com/ocaml/dune/pull/11485 ). It hasn't been accepted yet, but there's hope. Cheers, J.Puydt
