Contribution Guidelines

[Leon0402]

As I said in the other project, I feel like a cmake init script is something we really needed and this is quite a good start!

I do see the problem though that cmake is quite opinion based in many ways. Obviously there are some best practices like use targets everywhere. But there are a lot of things, which are discussable or completly based on preference.
So two common acceptable options would be:

• Make it configurable
• Don't do it if it's controversial

The first option is great for many things, but making everything configurable can be too much at some point. You don't wanna go through a 2h init setup questions neither is it something you wanna maintain I suppose.
So just asking for important stuff like you do now seems good to me.

Just not doing controversial things isn't the worst thing either. At some point it's good to not implement too much, which 80% don't agree with.

But I see some points that are controversial, a pain in the ass to make too configurable, but relevant to a lot of people. One of these is probably dependency management. There are a few options, which one could make configurable. But for all the methods there are also a few ways you could do it.

So I want to propose a general mechanism to deal with this thing. For things that are important and need a decision, just decide. But open up an issue where people can discuss about it. And then document why in particular you made decision xyz and how people could tweak it perhaps, if it doesn't fit for them. This way we have sort of "best practices" and also document them.
In such starter templates I often wonder if there is any rationale behind some certain things. At least for more complex stuff.

An example: Say we add support for a testing framework (GTest) and allow one to use find_package or FetchContent for it (or CPM .. or git submodule or ...).
Say then we want to add the FetchContent part ... how would you do it? Where put the call? When call FetchContent ... when MakeAvailble?
There are a few options here.

One good approach is creating a "dependencies" folder, then list all FetchContent() Calls and then make a folder for each dependency and put in there each MakeAvailable Call. This is one of many approaches, a good one I would say. For a lot of users it might be super confusing why anyone would do it like this.
There are a few reasons here:

• Putting it in a subdirectory leads to a clean separation (every seen this huge single root Cmake Files?)
• Listing all FetchContent Calls first is more efficient in case dependencies share dependencies. Also allows to overwrite a few things
• Putting all MakeAvailable Calls in a new file / folder puts them in a new scope. Therefore variables can be set just for that particular project. For example say you need LIB XYZ as shared, put a set(BUILD_SHARED_LIBS ON) before ... works and doesn't affect anything else
  ...

It doesn't mean this is the perfect or only approach. But I think it's better to include something than nothing, especially if a lot of people need it. But without any explanation it would be weird for a lot of people. And perhaps this is also something not one person alone should decide, at least not if the overall goal is to make this the "agreed best practice init script".

So a discussion issue + documentation on the decision (with perhaps background information) for all these things would help a lot I would say.

[friendlyanon]

I'm not sure what is being asked here. Are you asking about dependency management?
There are example repositories in the readme using vcpkg and Conan outlining exactly what needs to be done to integrate with those. With passing CI to boot!

[Leon0402]

Hmm maybe I was unclear. In a lot of projects I see the issue that someone suggest something he considers a "best practice", which then gets just merged. A few month later someone else comes and says the opposite ...

Or another common thing is that it's just not clear why something was done the way it was done. I often see this problem also with these static cmaker starter projects. Things are done and it's not clear why.

So I thought how one could solve these two issues:

• Introduced changes which are quite opinion based
• Introduced changes where there reasoning is not clear

Up to now you have written this script probably based on your personal experience and best practices. This is perfectly fine, especially for a lot of the basic setup. For a lot of things there is a clear best practice, I agree with a lot you did here.
But that might not be the case in the future when it's more about some special features or details.

I assumed that you would like the init script to be agreed on in the community and actually to be considered "best practice". So make this more community driven.
Maybe I'm wrong with that, maybe this project is mostly for yourself and you want to decide what's good and what's not completly on your own. That's a valid approach.

In case you want the first thing, a tool for the community, accepted by the community I proposed to add a "CONTRIBUTING.md" and add some base rules.
The two I proposed where:

• Every new feature should have an issue before and should be discussed
• A possible controversial change should be documented, so people can understand why a thing was done how it was done

The examples in the post above where meant to show such "controversial things", but it seems it lead to more confusion than it helped.

So my post was basically about: How is this tool developed? Who decides how to move forward? What is the role of the community?

I see now that I made some assumptions about the goal of the projects (i.e. that it is or will be community driven) that might not be true. Sorry for the confusion.

[friendlyanon]

Ah, so this is basically a request for a CONTRIBUTING document for cmake-init itself?
Yeah, that's doable.

For the rest:
The core concepts of cmake-init are derived from Craig Scott's Deep CMake for Library Authors talk. It provided a strong basis on which I could expand upon. I know he also has a book, but I have not purchased it, so I don't know anything about its contents.
Having strict warnings enabled and many tools integrated by default came from Jason Turner. USE ALL THE TOOLS! Except not really, but some are an absolute must and those are in cmake-init (to my knowledge).
Everything else is just me applying a generous amount of common sense and discipline.