Yes, you are right, but I do not want to standardize a build system.

I wanted a constexpr filesystem (and file io) that could be optionally enabled.

I don’t want to make this about build systems , but about constexpr filesystem api. I was simply pointing out that most of the problems raised by REs here can be adressed, not in a theoretical way but in a practical way ( I was working on containerized, secured, reproducible builds in containers quite a long time ago).


On Tue, Mar 12, 2024, at 14:25, Andrey Semashev via Std-Proposals wrote:
> On 3/12/24 15:03, Andrei Grosu via Std-Proposals wrote:
>> You are right, I will return with a complete example to explain the
>> problem, but , unrelated to my specific use case, the problems you and
>> someone else raised are non-problems from my perspective:
>>
>> All builds are made in containers that I define and are by definition
>> reproducible builds. There are pretty strong guarantees that a
>> container-based reproducible build system guarantees the exact same
>> environment, including the filesystem . Similarly, any security concers
>> of Marcin are moot : any changes will be local to that container.
>> I agree that maybe containerized, reproducible build systems are not the
>> norm in the c++ world, but still.
>>
>> But thanks for the input.
>
> Build environment is out of scope of the C++ standard. Whatever language
> feature you propose, must work well in any reasonable build environment.
>
>> On Tue, Mar 12, 2024, at 13:49, Matthew Taylor wrote:
>>> Granted, I'm not as familiar as some to the specific needs of writing
>>> a build system, but could you elaborate further on specifically what
>>> you want and specifically why it would be an improvement? Just adding
>>> constexpr to filesystem operations seems like it has a large area of
>>> confusion for the obvious reason of there being no guarantee that a
>>> program will be compiled and run on the same filesystem (as well as a
>>> few other reasons of varying obviousness).
>>>
>>>
>>> Are you looking for a facility like #embed, to directly embed file
>>> data into your source code? Or are you thinking of the possibility of
>>> more complex file manipulation performed by the compiler?
>>
>>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals