This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 10/31/2017 08:47 PM, Trevor Saunders wrote:
It sounds so easy, but it does get more complex than just build and tar the result up. How (for example) do you handle DSOs that may or may not be on the system where the bits get installed. Do you embed them or tell the user to go get them? That's just one example of a gotcha, there's many.On Tue, Oct 31, 2017 at 11:38:48AM -0600, Jeff Law wrote:On 10/31/2017 11:22 AM, Eric Botcazou wrote:I don't see a reason not to other than a pretty small amount of work each time we make a release.I'm not sure it would be so small an amount of work, especially on non-Linux platforms, so this would IMO divert our resources for little benefit.Having done this for years on HPUX, yes, it takes more time than one could imagine. THen I went to work for a company that did this for hpux, solaris, aix, irix and others and well, it was very painful.I'm sure its a project one can spend arbitrary amounts of time on if one wishes or is payed to do so. That said I'm considering the scope here limitted to running configure / make / make install with the defaults and taring up the result. I'll admitt I've only done that on linux where it was easy, but people do keep AIX and Solaris building and they really are supposed to be buildable in a release. However at some point it can be less work to do this than to beat C++98 into doing what is desired.
It's really not something I'd suggest we pursue all that deeply. Been there, done that wouldn't want to do it again.
In my particular case I could use certain C++11 features to make the code cleaner/easier to prove right -- particularly rvalue references and move semantics. I've got an object with a chunk of allocated memory. I want to move ownership of the memory to another object.Thirdly making it easier to work on the compiler and understand it makes things easier for those possible contributors, so if being able to use C++11 advances that goalthings could be better over all for possible contributors with different system compilers.I don't buy this at all. You don't need bleeding edge C++ features to build a compiler and people don't work on compilers to use bleeding edge C++. Using a narrow and sensible set of C++ features was one of the conditions under which the switch to C++ as implementation language was accepted at the time.Agreed that we need to stick with a sensible set of features. But the sensible set isn't necessarily fixed forever.Also as a counter example what brought this thread up is Richard wanting to use something from C++11. So in that particular case it probably would make something better.
C++11 handles this cleanly and gracefully and in doing so makes it very hard to get it wrong.
However, I don't think my case, in and of itself, is enough to push us into the C++11 world. Nor am I convinced that the aggregate of these things is enough to push us into the C++11 world. But I do think we'll be there at some point.
jeff
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |