In my limited experience, unless you hard-specify the location of that
file, then eventually, different tools will have those files in different
places and the build tools will again now need to write compiler specific
options to fetch the files. Finally, if you have multiple of compilers
installed, then we risk picking up the wrong file.

On Fri, 2 Jun 2023, 23:06 Tom Honermann via SG15, <sg15_at_[hidden]>
wrote:

> On 6/2/23 4:46 PM, René Ferdinand Rivera Morell via SG15 wrote:
> > On Fri, Jun 2, 2023 at 2:38 PM Tom Honermann <tom_at_[hidden]> wrote:
> >> On 6/2/23 2:52 PM, René Ferdinand Rivera Morell via SG15 wrote:
> >>> I'll need to do some research on the possibility of having side data
> >>> as a mechanism. I.e. go find out how it would work in the variety of
> >>> build, packaging, and compiler tools that are available. But I'm
> >>> wondering, since both Gaby and Olga mentioned it, if you can give
> >>> examples of running such tools in size constrained environments and
> >>> multiple tools needing to communicate. As I'm not familiar with
> >>> running compilers, build systems, and package managers outside of
> >>> desktop environments.
> >> CI deployments are often configured such that development tools are
> >> deployed into a fresh OS image as part of job processing. The smaller
> >> the size of the tools, the lower the setup overhead, the faster the job
> >> throughput.
> > Interesting.. The CI systems I work with are either in-house to build
> > rather large Unreal Engine based projects, or cloud based ones to
> > build & test (in comparison) small projects like Boost C++ Libraries.
> > For the former the size & resources doesn't matter at the scale of
> > adding a command line option in a tool having an impact on anything.
> > As everything is pre-installed as it's impractical to do otherwise.
> > And as some parts of it run in a local network distributed compute
> > structure. For the cloud based ones, yes, most of the setup of OS and
> > tools is pre-imaged somehow. So I guess I'm trying to understand what
> > you mean by "fresh OS image". Does that mean you install an empty OS
> > and then fresh install tools and then build/test? Something else?
>
> In at least some of the environments I've worked in, there have been a
> limited number of base OS images provided and customization gets
> expensive due to frequent updates and differing project and project
> version dependencies. That means that suitable images are constructed on
> demand to meet job requirements.
>
> By "install" I mean some form of making development tools available on
> the image. For a few annoying products, that means having to automate
> execution of an installer, but most development tools are sufficiently
> well behaved that copying an "installed" image of the tool from
> somewhere else to a local location works fine.
>
> Tom.
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>