C++ Logo

sg15

Advanced search

Re: [isocpp-ext] Can we expect that all C++ source files can have the same suffix?

From: Gabriel Dos Reis <gdr_at_[hidden]>
Date: Wed, 20 Apr 2022 19:58:01 +0000
  * 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.

Understood, and appreciated.

-- Gaby

From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Bret Brown via SG15
Sent: Wednesday, April 20, 2022 12:48 PM
To: SG15 <sg15_at_[hidden]>
Cc: Bret Brown <mail_at_[hidden]>; René Ferdinand Rivera Morell via Ext <ext_at_[hidden]>; Tom Honermann <tom_at_[hidden]>; Nathan Sidwell <nathan_at_[hidden]>; Peter Dimov <pdimov_at_[hidden]>
Subject: Re: [SG15] [isocpp-ext] Can we expect that all C++ source files can have the same suffix?

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]<mailto: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]<mailto: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]<mailto:SG15_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/sg15<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&data=05%7C01%7Cgdr%40microsoft.com%7C2642af8387354bdadc2e08da2306aef1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637860808887615952%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Kfo2ySAY%2FO1q98ymrXQeID%2Fwfe4RrvI1XPhCYY5E25A%3D&reserved=0>

Received on 2022-04-20 19:58:04