Should the repository names be named after the full project name? E.g. beman.exemplar instead of exemplar

[camio]

The repository name is one of only places where we don't use the full project name when we're not otherwise forced to use something else.

One benefit is that a checkout of the repository is less likely to clash with another repository checkout in the same enclosing directory. I typically have several Open Source repositories checked out in a single folder, but for beman projects I create a bemanproject/ subfolder.

Another benefit is it is much clearer that the checkout is a beman project.

[wusatosi]

I think this is extra noise. I think the checkout directory would be the only benefit of this.
Which would be easily mitigated on the user side, e.g. git clone github.com/bemanproject/exemplar.git beman-exemplar.

I can see how this would be beneficial for mega repos (e.g. llvm/llvm-project), but I don't think this make sense for us. Current GitHub repos are clear enough.

[neatudarius]

The repository name is one of only places where we don't use the full project name when we're not otherwise forced to use something else.

One benefit is that a checkout of the repository is less likely to clash with another repository checkout in the same enclosing directory. I typically have several Open Source repositories checked out in a single folder, but for beman projects I create a bemanproject/ subfolder.

Another benefit is it is much clearer that the checkout is a beman project.
I was thinking about the same thing when we started Beman and I didn't propose that because we'll end up having something like https://github.com/bemanproject/beman.examplar - duplication.

Now I'm strongly in favor to rename all repos to use beman.$short_name. It will actually help new users.

[ClausKlein]

How do you plan a super build?

With git submodules like boost?

[wusatosi]

I don't think this should be a exemplar question.
We should prob post this on discourse

[neatudarius]

How do you plan a super build?

With git submodules like boost?

We don't plan to use submodules, we previously discussed and removed all submodules from our org. Probably, cmake fetch content is our status quo - I need to check the minutes from previous sync meetings.

I don't think this should be a exemplar question.
We should prob post this on discourse

Agree, we can keep it for next time. I won't duplicate the thread right now.

[wusatosi]

I think we should move this to discourse/ beman repo.

This is a suggestion that impacts all repos, and the thread is not too big yet. exemplar do not get enough attention and we risk having a dangling issue here.

git submodule

Can we have this codified in a documentation under beman repo?

[neatudarius]

git submodule

Can we have this codified in a documentation under beman repo?

Added to agenda for next Monday.

[neatudarius]

git submodule

Can we have this codified in a documentation under beman repo?

Added to agenda for next Monday.

Will be solved in bemanproject/beman#75

[bretbrownjr]

How do you plan a super build?

@ClausKlein Right now, FetchContent is the trivially supportable option.

I would like to see someone (me if I have time) provide sufficiently mature Beman libraries via Conan and vcpkg one way or another at some point. I wouldn't oppose anyone that wanted to add support for other package managers as well: Arch AUR, nix, etc.

That being said, I would hate to see anything intrusive in each of the Beman projects to support all of that. I would expect that using well-constructed CMake would be sufficiently portable to support any of the above. If not, let's make bug reports and update our tooling and standards accordingly.

[neatudarius]

Today we decided to reject this proposal at 2025-01-20 Beman Weekly sync. It was discussed and we took a final decision.

FYI @bemanproject/leads