Date: Fri, 4 Mar 2022 17:24:13 +0000
* The existence and ramifications of today's world of headers + library objects is important to draw from to understand the nature of the situation for many users today and how that will change/regress/become more difficult with modules under certain circumstances. It's a really important starting point for the conversation, in my opinion.
Correct. Which is why starting from libraries (as opposed to modules) as units has better chances of providing path to a solution.
-- Gaby
From: David Blaikie <dblaikie_at_[hidden]>
Sent: Friday, March 4, 2022 9:18 AM
To: Gabriel Dos Reis <gdr_at_[hidden]>
Cc: David Blaikie via SG15 <sg15_at_[hidden]>
Subject: Re: [SG15] Meeting on Friday March 4th at 9AM Pacific.
On Fri, Mar 4, 2022 at 9:14 AM Gabriel Dos Reis <gdr_at_[hidden]<mailto:gdr_at_[hidden]>> wrote:
My suspicion is that "modules" as units complicates more the conversation than clarifies things. As evidenced by examples given throughout where people keep falling back to today's conventional world of headers+library objects.
The existence and ramifications of today's world of headers + library objects is important to draw from to understand the nature of the situation for many users today and how that will change/regress/become more difficult with modules under certain circumstances. It's a really important starting point for the conversation, in my opinion.
- Dave
-- Gaby
________________________________
From: David Blaikie <dblaikie_at_[hidden]<mailto:dblaikie_at_[hidden]>>
Sent: Friday, March 4, 2022 9:10:18 AM
To: David Blaikie via SG15 <sg15_at_[hidden]<mailto:sg15_at_[hidden]>>
Cc: Gabriel Dos Reis <gdr_at_[hidden]<mailto:gdr_at_[hidden]>>
Subject: Re: [SG15] Meeting on Friday March 4th at 9AM Pacific.
On Fri, Mar 4, 2022 at 8:48 AM Gabriel Dos Reis via SG15 <sg15_at_[hidden]<mailto:sg15_at_[hidden]>> wrote:
A library can be madr of several modules, so if the hypothesis is that only modules interface files (e.g. ixx or cppm files) are provided for that library along with a static or shared object, why are we focusing on modules as basic units instead of taking libraries as basic units?
Using libraries as the unit is what Daniel's other thread/proposal "Exploring another alternative for Distributing C++ Module Libraries" explored - looking up the library location (doesn't work for header-only libraries, though, and requires either some interaction with the linker, or duplicating some of the linker search logic) and then finding a configuration file there that described all the modules owned by the library.
I think we started with modules as the unit because it potentially simplified discovery - by using the module name to locate the module interface source and its build configuration information. (still another search-path to search, but maybe a simpler one than the library search path with its extra suffixes and prefixes? Not sure)
-- Gaby
________________________________
From: SG15 <sg15-bounces_at_[hidden]<mailto:sg15-bounces_at_[hidden]>> on behalf of René Ferdinand Rivera Morell via SG15 <sg15_at_[hidden]<mailto:sg15_at_[hidden]>>
Sent: Friday, March 4, 2022 8:37:31 AM
To: ISO C++ Tooling Study Group <sg15_at_[hidden]<mailto:sg15_at_[hidden]>>
Cc: René Ferdinand Rivera Morell <grafikrobot_at_[hidden]<mailto:grafikrobot_at_[hidden]>>
Subject: Re: [SG15] Meeting on Friday March 4th at 9AM Pacific.
On Fri, Mar 4, 2022 at 10:25 AM Olga Arkhipova via SG15 <sg15_at_[hidden]<mailto:sg15_at_[hidden]>> wrote:
Boost is header only (IIRC), so user just needs to add its directories to the Include dirs.
Boost is a mixture of header-only, header+source, and dual-mode individual libraries. Although the default distribution of Boost is source without binaries. The binaries, i.e. DLLs and/or LIBs, are generated by users and packaging providers.
Correct. Which is why starting from libraries (as opposed to modules) as units has better chances of providing path to a solution.
-- Gaby
From: David Blaikie <dblaikie_at_[hidden]>
Sent: Friday, March 4, 2022 9:18 AM
To: Gabriel Dos Reis <gdr_at_[hidden]>
Cc: David Blaikie via SG15 <sg15_at_[hidden]>
Subject: Re: [SG15] Meeting on Friday March 4th at 9AM Pacific.
On Fri, Mar 4, 2022 at 9:14 AM Gabriel Dos Reis <gdr_at_[hidden]<mailto:gdr_at_[hidden]>> wrote:
My suspicion is that "modules" as units complicates more the conversation than clarifies things. As evidenced by examples given throughout where people keep falling back to today's conventional world of headers+library objects.
The existence and ramifications of today's world of headers + library objects is important to draw from to understand the nature of the situation for many users today and how that will change/regress/become more difficult with modules under certain circumstances. It's a really important starting point for the conversation, in my opinion.
- Dave
-- Gaby
________________________________
From: David Blaikie <dblaikie_at_[hidden]<mailto:dblaikie_at_[hidden]>>
Sent: Friday, March 4, 2022 9:10:18 AM
To: David Blaikie via SG15 <sg15_at_[hidden]<mailto:sg15_at_[hidden]>>
Cc: Gabriel Dos Reis <gdr_at_[hidden]<mailto:gdr_at_[hidden]>>
Subject: Re: [SG15] Meeting on Friday March 4th at 9AM Pacific.
On Fri, Mar 4, 2022 at 8:48 AM Gabriel Dos Reis via SG15 <sg15_at_[hidden]<mailto:sg15_at_[hidden]>> wrote:
A library can be madr of several modules, so if the hypothesis is that only modules interface files (e.g. ixx or cppm files) are provided for that library along with a static or shared object, why are we focusing on modules as basic units instead of taking libraries as basic units?
Using libraries as the unit is what Daniel's other thread/proposal "Exploring another alternative for Distributing C++ Module Libraries" explored - looking up the library location (doesn't work for header-only libraries, though, and requires either some interaction with the linker, or duplicating some of the linker search logic) and then finding a configuration file there that described all the modules owned by the library.
I think we started with modules as the unit because it potentially simplified discovery - by using the module name to locate the module interface source and its build configuration information. (still another search-path to search, but maybe a simpler one than the library search path with its extra suffixes and prefixes? Not sure)
-- Gaby
________________________________
From: SG15 <sg15-bounces_at_[hidden]<mailto:sg15-bounces_at_[hidden]>> on behalf of René Ferdinand Rivera Morell via SG15 <sg15_at_[hidden]<mailto:sg15_at_[hidden]>>
Sent: Friday, March 4, 2022 8:37:31 AM
To: ISO C++ Tooling Study Group <sg15_at_[hidden]<mailto:sg15_at_[hidden]>>
Cc: René Ferdinand Rivera Morell <grafikrobot_at_[hidden]<mailto:grafikrobot_at_[hidden]>>
Subject: Re: [SG15] Meeting on Friday March 4th at 9AM Pacific.
On Fri, Mar 4, 2022 at 10:25 AM Olga Arkhipova via SG15 <sg15_at_[hidden]<mailto:sg15_at_[hidden]>> wrote:
Boost is header only (IIRC), so user just needs to add its directories to the Include dirs.
Boost is a mixture of header-only, header+source, and dual-mode individual libraries. Although the default distribution of Boost is source without binaries. The binaries, i.e. DLLs and/or LIBs, are generated by users and packaging providers.
-- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Frobot-dreams.net%2F&data=04%7C01%7Cgdr%40microsoft.com%7Ce55ac020b81b458042ee08d9fe02fb21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637820111039865457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=4viTCdrI7v9%2FwoO%2B3hXq2qagGc5oCqBPq9Isove4u9A%3D&reserved=0> _______________________________________________ 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=04%7C01%7Cgdr%40microsoft.com%7Ce55ac020b81b458042ee08d9fe02fb21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637820111039865457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=2ZsMuIhGUky%2BHKkoYU4yhDMDj8QXx1RdT2A5HZzcWbw%3D&reserved=0>
Received on 2022-03-04 17:24:18