How many people have experience providing tools to customers or code they
don't control? I'd like to get a sense of where this is concrete and where
this is assumption?

On Wed, Apr 4, 2018 at 6:08 AM Mathieu Ropert <mro_at_[hidden]> wrote:

> I agree that a long term goal would be to require as little configuration
> as possible to build a project.
>
> I believe one thing we could look at is why so many projects rely on
> complex configuration, macros and whatnot.
> (For example in my experience it was mostly due to portability concerns,
> either to work around compiler/platform quirks or because C++ didn't offer
> a portable solution to the problem)
>
> From there we could make recommendations to improve the language based on
> what we found lacking or requiring some workaround.
> As Gaby said, if something (or lack thereof) is making tooling (and
> building) hard, we should try to address it.
>
> Cheers,
> Mathieu
>
> On Wed, Apr 4, 2018 at 9:17 AM, Corentin <corentin.jabot_at_[hidden]> wrote:
>
>> But that's specifically why I think current tooling don't work reliably.
>> Of course compilers are seeing the code a certain way.
>> But developers work on all of the code. A project being a cohesive set of
>> files.
>> There should be ( on new code ) no need for any more external information
>> that "this is a set of files".
>> Point the tool towards a directory and refactor to you heart content.
>> Build systems are extremely important but should not be necessary for
>> anything but building.
>>
>> Indexing, symbol renaming, doc generation, etc should probably not
>> require a full blown build system to work.
>> And it should work on the code rather than a partial, incomplete view of
>> the code.
>> Do we really think sidestepping this issue by running the tool for each
>> known configuration ( a number which explodes exponentially as you
>> mentioned) is a satisfactory long term solution ?
>>
>> Can we make source files self-sufficient sources of truth ? That's a goal
>> I would like to see explored.
>>
>> We of course agree that tooling implies having a solid continuous
>> integration / test suite.
>>
>>
>> PS : I didn't receive Gaby's email either.
>>
>>
>> Le mer. 4 avr. 2018 à 08:31, Peter Sommerlad <peter.sommerlad_at_[hidden]> a
>> écrit :
>>
>>> Another CHF0.02:
>>>
>>> One important aspect for all kind of tooling is to have a way what
>>> consists of a 'build' or project. A lot of tooling as well as IDE suffer
>>> from the user experience for setting up a 'project' and get all settings
>>> correctly, so that tools see the same code in the same way as the ultimate
>>> compiler and linker are seeing it. The separate compilation model inherited
>>> from C that was rooted in the limited hardware platforms of the 1970s might
>>> no longer be appropriate, but separation of work is still important.
>>>
>>> May be this should even be a short term goal to standardize:
>>> * what makes the whole executable program/object code?
>>> * what build modes exist for a specific chunk of code? How do they
>>> combine with other chunks' build modes? How to reign the explosion of
>>> potential combinations to a practical limit?
>>>
>>> Regards
>>> Peter
>>>
>>>
>>>
>>> Sent from Peter Sommerlad's iPad
>>> +41 79 432 23 32 <+41%2079%20432%2023%2032>
>>>
>>> On 4 Apr 2018, at 02:03, Gabriel Dos Reis <gdr_at_[hidden]> wrote:
>>>
>>> I will add my piece about long term goals later, but I just want to
>>> emphasize Titus here:
>>>
>>>
>>>
>>> - Refactoring isn't near impossible, it's just hard.
>>>
>>>
>>>
>>> Absolutely.
>>>
>>> It would a fundamental mistake for SG15 to make, and WG21 to copy, in
>>> thinking that a tooling capability is an issue only if it is (nearly)
>>> impossible. If we are making something hard, or harder, we must think
>>> twice. Or thrice. When you make tooling harder, you are potentially
>>> reducing its availability. Think about it.
>>>
>>>
>>>
>>> -- Gaby
>>>
>>>
>>>
>>> *From:* tooling-bounces_at_[hidden] <tooling-bounces_at_[hidden]> *On
>>> Behalf Of *Titus Winters
>>> *Sent:* Tuesday, April 3, 2018 12:40 PM
>>> *To:* WG21 Tooling Study Group SG15 <tooling_at_[hidden]>
>>> *Subject:* Re: [Tooling] Proposed mission
>>>
>>>
>>>
>>> Refactoring isn't near impossible, it's just hard. (See most of the
>>> talks that Google has given at CppCon for the last few years - there's
>>> massive refactoring mentioned in most or all of 'em.)
>>>
>>>
>>>
>>> Macros are hard, but not that hard. Inappropriate/unsupported usage of
>>> an API causes far more pain - you can see stories about that in
>>> https://www.youtube.com/watch?v=u5senBJUkPc
>>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3Du5senBJUkPc&data=02%7C01%7Cgdr%40microsoft.com%7Caf4dfe1ed52f4a49e47308d5999aac2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636583811954972136&sdata=KJzWRGPGtoEIGcriui98rY8UJHYMDh1L3vWDHEKiA9s%3D&reserved=0> or
>>> the rules we've had to come up with in Abseil compatibility (
>>> https://abseil.io/about/compatibility
>>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fabseil.io%2Fabout%2Fcompatibility&data=02%7C01%7Cgdr%40microsoft.com%7Caf4dfe1ed52f4a49e47308d5999aac2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636583811954972136&sdata=f%2FeQeCrCSGhRdCpRd3j1dCKZGNDV%2BwqsLh47QZIhCa8%3D&reserved=0>)
>>> or my proposal at the standards level (http://wg21.link/p0921
>>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwg21.link%2Fp0921&data=02%7C01%7Cgdr%40microsoft.com%7Caf4dfe1ed52f4a49e47308d5999aac2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636583811954972136&sdata=F%2F45MhDyhdAcjLvElRHDM7fMzP2NPd9TmAdH2us9mEY%3D&reserved=0>).
>>> But the tools we rely upon internally work because we control the build
>>> system and toolchain. If an arbitrary project's build isn't understandable,
>>> tools won't work. Similarly, if a project is deeply dependent on the quirks
>>> of a single compiler and that vendor doesn't provide refactoring tools,
>>> then we (as the committee or as the community) cannot rely on the existence
>>> of those tools.
>>>
>>>
>>>
>>> But all of that is fairly tactical - I'd really like to think about this
>>> as a far bigger picture thing. Setting a good long-term mission that gets
>>> us all of these shorter-term goals as a side effect is a good way to
>>> structure things - if we agree on the long term, then minor chaos in the
>>> short term still leads us in the right direction without getting too hung
>>> up on people's differences in priorities for tactical decisions.
>>>
>>>
>>>
>>> On Tue, Apr 3, 2018 at 2:32 PM Corentin <corentin.jabot_at_[hidden]>
>>> wrote:
>>>
>>> I wasn't at Jacksonville.
>>>
>>> Were the current issues discussed ?
>>>
>>> Aka what makes refactoring near-impossible today ?
>>>
>>> Of course, I have an answer to that ( macros ) - but it's probably not
>>> the only pain point.
>>>
>>>
>>>
>>> I don't believe anything added after 98 made things fundamentally more
>>> complicated for tools.
>>>
>>> (Exporting-macro modules might...)
>>>
>>>
>>>
>>> Once we identify the actual pain points it will be easier to work around
>>> them.
>>>
>>> Probably by introducing new language constructs - Lots of very smart
>>> people tried to make refactoring work over the past 30 years, I don't
>>> believe SG15 can improve on the state of the art without taking a
>>> completely new approach.
>>>
>>>
>>>
>>> So, here is an attempt to reformulate Titus' goal:
>>>
>>>
>>>
>>> Refactoring tools that people can trust blindly. (either because the
>>> tool works 100% of the time or notifies the user about 100% of the failure
>>> cases).
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Le lun. 2 avr. 2018 à 22:08, Timur Doumler <cpp_at_[hidden]> a écrit :
>>>
>>> Hi Titus,
>>>
>>>
>>>
>>> While I think this is a great long-term mission, I believe this leaves
>>> out a big area where SG15 can provide value today, in the more immediate
>>> term.
>>>
>>>
>>>
>>> I believe we should spend some time on questions like:
>>>
>>>
>>>
>>> - What language features, that WG21 is working on today, make it harder
>>> (or easier) to write good tools for?
>>>
>>> - Are there areas where SG15 can provide guidance to WG21? Think about
>>> this scenario. New shiny language feature X has two possible design
>>> directions, A and B. Both seem to solve the problem similarly well.
>>> However, direction A would create a major pain-in-the-butt for tools
>>> vendors, whereas direction B wouldn’t. Should we not monitor, detect, and
>>> discuss such cases and then feed our insights back into WG21?
>>>
>>> - Are there areas where, instead of adding more stuff to C++, the
>>> problem would be more adequately solved with tooling?
>>>
>>> - Are there areas where language features pose significant challenges
>>> for tool vendors, and where it could be good for everyone if we had a
>>> platform to synchronise on those challenges? (*cough* *cough* modules
>>> *cough*)
>>>
>>>
>>>
>>> Cheers,
>>>
>>> Timur
>>>
>>>
>>>
>>>
>>>
>>> On 2 Apr 2018, at 21:08, Titus Winters <titus_at_[hidden]> wrote:
>>>
>>>
>>>
>>> At the recent evening session in Jacksonville, many many things were
>>> brought up in the realm of "tooling." These ranged all across the spectrum
>>> of engineering tools, from IDE support, dependency management / discovery,
>>> distribution, refactoring, and a host of other things.
>>>
>>>
>>>
>>> On the fly, I tried to cobble those into a coherent goal for SG15 and
>>> the committee to aim toward. It's currently phrased very much for the
>>> committee audience (that's been part of my delay in re-summarizing here),
>>> but as with any good mission statement I think it gets direction and
>>> incentive structures aligned with the greater good. Put another way: it's
>>> phrased selfishly, but hopefully produces great results for the entire
>>> community.
>>>
>>>
>>>
>>> So, here is that proposed mission statement:
>>>
>>>
>>>
>>> In 10 years, the committee should be able to run compiler-informed
>>> queries against a significant fraction of the open-source C++ community and
>>> use that to inform deployment of refactoring tools to mitigate.
>>>
>>> - Consistent build understanding
>>> - Consistent package distribution / identification
>>> - Provide static analysis and refactoring to help provide users easy
>>> upgrades and modernization
>>>
>>>
>>>
>>> Obviously this would be a huge task that requires support from many
>>> chunks of the community - WG21 cannot be solely responsible, and it's
>>> outside of what WG21 is normally great at. But we can help set direction,
>>> plan, prioritize, and lend support to ideas that emerge along these lines.
>>>
>>>
>>>
>>> So, I'd like to hear from everyone a bit: is this a good direction? Does
>>> it capture what we'd like? Can we phrase it less selfishly?
>>>
>>>
>>>
>>> If we're happy with holding this up as the long-term goal, we'll need to
>>> break it down into more manageable pieces. I've privately asked a couple
>>> people to sketch out what they envision it would take to get from where we
>>> are to that proposed future. I'd like to broaden that call, and we'll look
>>> collectively at those break-downs to try to formulate next steps.
>>>
>>>
>>>
>>> Thoughts?
>>>
>>> -Titus
>>>
>>>
>>>
>>> PS: I've also just completed a big round of offloading in my day job, so
>>> hopefully I'll have more cycles to pay attention to discussion on this
>>> list. My apologies for my scattered attention so far.
>>>
>>> _______________________________________________
>>> Tooling mailing list
>>> Tooling_at_[hidden]
>>> http://www.open-std.org/mailman/listinfo/tooling
>>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fmailman%2Flistinfo%2Ftooling&data=02%7C01%7Cgdr%40microsoft.com%7Caf4dfe1ed52f4a49e47308d5999aac2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636583811954972136&sdata=SQ54mcv5q5n5tSJzpLy6Cl5azaR2XG0a7J8GSYpi3WA%3D&reserved=0>
>>>
>>>
>>>
>>> _______________________________________________
>>> Tooling mailing list
>>> Tooling_at_[hidden]
>>> http://www.open-std.org/mailman/listinfo/tooling
>>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fmailman%2Flistinfo%2Ftooling&data=02%7C01%7Cgdr%40microsoft.com%7Caf4dfe1ed52f4a49e47308d5999aac2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636583811954972136&sdata=SQ54mcv5q5n5tSJzpLy6Cl5azaR2XG0a7J8GSYpi3WA%3D&reserved=0>
>>>
>>> _______________________________________________
>>> Tooling mailing list
>>> Tooling_at_[hidden]
>>> http://www.open-std.org/mailman/listinfo/tooling
>>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fmailman%2Flistinfo%2Ftooling&data=02%7C01%7Cgdr%40microsoft.com%7Caf4dfe1ed52f4a49e47308d5999aac2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636583811954972136&sdata=SQ54mcv5q5n5tSJzpLy6Cl5azaR2XG0a7J8GSYpi3WA%3D&reserved=0>
>>>
>>> _______________________________________________
>>> Tooling mailing list
>>> Tooling_at_[hidden]
>>> http://www.open-std.org/mailman/listinfo/tooling
>>>
>>> _______________________________________________
>>> Tooling mailing list
>>> Tooling_at_[hidden]
>>> http://www.open-std.org/mailman/listinfo/tooling
>>>
>>
>> _______________________________________________
>> Tooling mailing list
>> Tooling_at_[hidden]
>> http://www.open-std.org/mailman/listinfo/tooling
>>
>>
> _______________________________________________
> Tooling mailing list
> Tooling_at_[hidden]
> http://www.open-std.org/mailman/listinfo/tooling
>