Also, if you give me a function called std::compile(), that compiles code, it seems I can now write a compiler?
system seems like a precedent for what you suggest, and in my experience system isn't a precedent people want us to repeat.
"std::system" is what the sample implementation uses.. but it's possible you could implement it as a direct library call (easily doable for Clang, for example). And ideally production implementations would use something more robust than std::system ;-)
What's the upside of a library call?
One upside is that it's a known viable mechanism that can be standardized.
What's the upside of this, when build systems already handle this?
Build systems barely handle it.
I disagree: we manage to build code today. Works pretty well. The difficulty of build systems isn't mapping compiler options, it's all the other stuff around it.
I disagree... In that it works pretty well ;-) And, yes, that are other problems with "stuff around it". But what's the point of trying to fix all that stuff that's around when you don't fix one problem at the core?
But it's not just build systems. It's anything that needs some understanding of the options, for example code editors, binary package managers, code analyzers, and so on.
Could your paper explain how these are helped by your proposal?
It could. But it will have to be limited.. As I would rather not write, as I don't have infinite time, a novel length proposal.
Keep in mind that standardization has downsides, such as making any additions very slow, and changes nearly impossible. If I add a new option tomorrow, nobody can use it with a standards-based mechanism. Who would want to use this mechanism, given such limits?
Yes, and I think that using a combination of the IS and SDs we can avoid the downsides. I.e. we can have a "stable" set of options in the IS combined with a more fluid set of options in SDs.
An SD is still way slower than the turnaround I have today.
I don't think so. An SD *could* be created / updated and approved in a day. How often do you do compiler releases that a one day turnaround on option changes would be a problem?
I get the impression you're going down a rabbit hole...
How is the design different from something like this:
One similarity is that both compile source :-) Another, is of course, that the clang driver (or front end) somewhat simulates the gcc front end. That pattern is not uncommon.. I mention one of them in the prior art section. Others are the various msvc compatible compilers, like Intel.
I'd expect not just a list of prior-art, but a comparison of what each does.
Good idea.. I'm not going to have time to write that comparison for R0 though :-(
Understood, could you leave a "future work" item for it?
Maybe the code will help explain what I have in mind:
Or, put another way, why can't a Python script be used to frob command-line parameters in the way you propose?
It could. Although that would be a tool and as such not something we could put into the IS.
That raises a wider question: is SG15 constrained to putting things into the IS? Is it constrained to adopting pure C++ solutions to all problems? You seem to answer "yes" to both questions.
No I did not answer "yes" to both. I explicitly mention using SDs as a viable method also. But unless something changes in the way WG21 works I don't see any other way outside out of the IS to have anything enforceable.
I'd like to see SG15 do things outside IS / SD.
Could you answer the other question: it sounds like you absolutely want this in C++, not elsewhere.
Although I think it would be good for some use cases to have the compile ability in C++... I would also be happy to have any *enforceable* method to standardize the APIs between the C++ ecosystem tools outside of the IS.
As it stands, being a work in progress draft (or proposal), yes it's less comprehensive than almost every other build system. But I don't think it needs to be comprehensive at this point. Perhaps by the time this gets to R2 it will be more comprehensive that most build systems.
OK, could you add this as a goal of the paper? It would have helped me understand where you're going with this.
and the compiler vendors are in a better position to define their option "abstraction".
Sure, all compilers have their own command-line parameters at the moment. Standardizing them seems to remove that "better position" from compiler vendors, or at a minimum impose a bunch more work on them.
I don't think it adds much work to compiler vendors, after all they already implement the option parsing. It does add work for tool vendors as they will have to adjust to the new options.
Sure the mapping isn't hard, the extra constraints are an annoyance. What adds a huge burden, were we to adopt this, is that my standard library now must include a compiler. On every single desktop, laptop, and device we ship.
I don't see how that's the case. You can have a version of the library that comes with the compiler that has the functionality. And another version (only changing in returning an error) that doesn't have the functionality.
Why would I want your proposal over CMake?
You would not choose it over CMake, or any other build system. But it would make the build system much easier to implement.
Is that a problem worth solving compared to other tooling problems?
Anything that makes our tools more consistent to help build understanding is worth it, IMO.
What I'm asking is for a prioritization. Given limited time and resources, compared to other tooling problems, which would SG15 pick first?
Right.. Prioritization is important. But right now I'm the only person with public proposals. When we have more proposals we can prioritize.