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@gmail.com>
Sent: Friday, March 4, 2022 9:18 AM
To: Gabriel Dos Reis <gdr@microsoft.com>
Cc: David Blaikie via SG15 <sg15@lists.isocpp.org>
Subject: Re: [SG15] Meeting on Friday March 4th at 9AM Pacific.

 

On Fri, Mar 4, 2022 at 9:14 AM Gabriel Dos Reis <gdr@microsoft.com> 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@gmail.com>
Sent: Friday, March 4, 2022 9:10:18 AM
To: David Blaikie via SG15 <sg15@lists.isocpp.org>
Cc: Gabriel Dos Reis <gdr@microsoft.com>
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@lists.isocpp.org> 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@lists.isocpp.org> on behalf of René Ferdinand Rivera Morell via SG15 <sg15@lists.isocpp.org>
Sent: Friday, March 4, 2022 8:37:31 AM
To: ISO C++ Tooling Study Group <sg15@lists.isocpp.org>
Cc: René Ferdinand Rivera Morell <grafikrobot@gmail.com>
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@lists.isocpp.org> 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

_______________________________________________
SG15 mailing list
SG15@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg15