For what it's worth, we have a little utility at Bloomberg that accepts
source files and generates portable CMakeLists.txt on the fly. We let CMake
deal with portability problems. It works great, actually.

It's not useful to just release it open source though. The biggest hangup
is actually that CMake isn't packaging-agnostic enough. Because nothing
really is.

Getting some support for packaging modules is basically the same problem.
When we get somewhere there and then come back and generalize the approach
to support textual inclusion workflows, a utility in this space becomes
sane to share.

On Wed, Apr 20, 2022, 13:29 Tom Honermann via SG15 <sg15_at_[hidden]>
wrote:

> On 4/20/22 12:55 PM, Daniel Ruoso wrote:
>
> On Wed, Apr 20, 2022, 12:49 Peter Dimov <pdimov_at_[hidden]> wrote:
>
>> In either case, the "proper way" to make things is with a Build System.
>>
>
> It sounds to me there's an opportunity for someone to create this "one
> line build system for trivial projects". It seems like it will be very
> popular.
>
> The difficulty with that is the large and diverse set of toolchains in
> existence. Doing this requires knowledge of individual toolchains.
>
> If implementors would like to get behind a universal-c++(-and-c)-driver
> effort and contribute changes needed for their implementations, then
> perhaps something like this could be possible.
>
> Tom.
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>