[build2] How to tag when having multiple packages in one git repo?

Klaim - Joël Lamotte mjklaim at gmail.com
Sat Jul 21 23:54:49 UTC 2018


On 21 July 2018 at 16:53, Boris Kolpackov <boris at codesynthesis.com> wrote:

> So the recommended way is to only use multi-package repositories for
> packages that are developed in locksteps (normally a library and an
> executable, say libsqlite3 and sqlite3).
>
>
Then I'm failing to see how something like a boost distribution would work
with build2?
That's the most well known example of libraries not developed in lockstep
but still distributed as if they where, but I know of some other examples
in some companies.
To be clear: (without using subrepos?) how would I make a snapshot of
versions of libraries that I guarantee to work when used together (after
testing) using build2?

Maybe the solution is to make another build2 (super) project that
represents the distribution and just "depends" on the libraries in question?
It just feels weird because it wouldn't have code.

I don't know if it's a good idea to do something like that (maybe it's
obsolete as soon as you have easy ways manage dependencies) but I'm just
imagining real setup I have seen.


> > For A, I'm not sure what tag naming would help with build2 automatic
> > detection. As I can't name tags "vX.Y.Z" without quickly getting into
> > trouble, I was considering doing something like "packagename-vX.Y.Z".
>
> This is incorrect on the conceptual level since you are still tagging
> a snapshot of the repository and therefore multiple packages.
>
>
Indeed.


> If you want to keep unrelated packages in the same repository then you
> probably shouldn't be tagging it with package versions (the C approach
> mentioned above).


So a repository version tag would indeed be better. Currently it would not
be taken into account by build2 except if part of the repository url.
(just stating what I understand, I'm not suggesting a solution)


> There are ideas to allow customizing which tags are
> considered for the default set via a configuration file stored in the
> "control" branch.
>
>
Could you clarify what you mean by "default set" exactly?

A Joël Lamotte
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.build2.org/archives/users/attachments/20180722/872e48ac/attachment.html>


More information about the users mailing list