Right. But are there tools (of any form) you've tried to get them to use
and failed?

On Thu, Apr 5, 2018 at 12:06 PM Howard Hinnant <howard.hinnant_at_[hidden]>
wrote:

> I don’t control any of my customers. They pretty much have free will. :-)
>
> Howard
>
> On Apr 5, 2018, at 11:46 AM, Titus Winters <titus_at_[hidden]> wrote:
> >
> > 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 or the rules we've had to
> come up with in Abseil compatibility (
> https://abseil.io/about/compatibility) or my proposal at the standards
> level (http://wg21.link/p0921). 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
> >>
> >>
> >>
> >> _______________________________________________
> >> 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
> >
> > _______________________________________________
> > 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
>