Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] More fixes for env vars on launch for msys2



On 2016-06-03 03:38 PM, Doug Schaefer wrote:
Thanks Marc,

On Fri, Jun 3, 2016 at 2:18 PM, Marc Khouzam <marc.khouzam@xxxxxxxxxxxx> wrote:
So part of me thinks it is great to have better MSYS2 support.
But the other part of me... well, you know me :-)
I'd like to at least explain why I wouldn't put this in RC4.

- From what I understand, this is not a regression, it is an improvement for better MSYS2 support
- Not putting it in only affects MSYS2 (and does not break it)
- Putting it in affects _all_ debug launches, not just MSYS2.  That is a high risk for a low benefit.
- The community has done detailed testing with RC2 [1] and won't have time to redo it
- This change is going in to our last build; what happens if we find a problem next week?
- We have precedent for such situations, for this release in fact, where we disabled parameter
        guessing [2] and delayed the full fix for a possible deadlock [3] because the bugs were
        found too late.


It's probably not a regression. It's a statement of how terrible the situation is for Windows developers versus Linux. On Linux, everything is in your PATH and just works. For Windows, that's not usually the case and we have autodiscovery to find MinGW. I've extended that to cover MSYS2 since it's a much more complete and up to date environment.

But I can't believe we let the situation pass where clicking on a binary and doing Run As fails. Maybe this is specific to MSYS2 which uses DLLs a bit more than the original MinGW. Either way, it's an unacceptable user experience.
I'm fairly sure MinGW has the same problem too. I.e. just running a hello world outputs nothing until you add Mingw/bin to the PATH.

At any rate, all my writing about CDT for Neon involves MSYS2, both as the toolchain of choice for Windows (and we talked about that before), and as a platform for Qt. I'd be embarrassed to write about it in the current state so that's why I'm working my tail off to get it at least presentable.

I think we have RCs specifically to help make those hard decisions easier.
It's because of these things that I seem to want to play the killjoy.

Now, if you feel you want this patch in 9.0, at RC4, and resolveMacro() is safe, then I'm not too
concerned about the getGDBVersion() change.  I believe we just forgot to remove its use when
we deprecated it. The impact it could have though, is that anyone overriding that method will
no longer be overriding it without making the correct changes for 9.0.

Thanks, Marc. That's the feedback I'm looking for. What are the real risks here that you can identify so I can test and mitigate them.

And I will have us set up to do a maintenance release if we have to to fix any emergency regressions. We should really consider how to release fixes as often as we can if we're not going to get much test coverage in certain areas like this.

BTW, I have given up on Mac for the time being until we get a debug story that's sane. I don't consider the magic to get Homebrew's gdb self-signed and certificates inserted into the keychain sane. lldb really has to be where we have to head there, through MI or otherwise.

About lldb, things are starting to work on Linux and Mac. I can debug a simple hello world program. I wanted to put that feature in CDT 9.0 but I think for 9.1 it will be a better candidate. So maybe you won't have to give up for very long :) What also helps is that lldb-mi is now shipped with Xcode by default, we just need to set the path for the user, whereas before we'd have to find a way do distribute it.

And I'm also very disappointed I'm the only one who cares about Windows developers. I'm not paid to do this and could easily drop it if others feel it's not important.
I think it's very important! I personally haven't had time to work more in this area lately. What would really help is if someone had a business case for it so that more time could be spent on improving the support and maintaining it.


Thanks!
Doug.
 


[1] https://docs.google.com/spreadsheets/d/1u8pQ0fJQkXdGTkFN6PgdlXHvGe6rv_e200gVyrP5Bzg/edit#gid=0
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=495095
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=494650




From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Doug Schaefer [cdtdoug@xxxxxxxxx]
Sent: June 3, 2016 1:29 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] More fixes for env vars on launch for msys2

Let's just say I wouldn't recommend using it on Windows. Mingw.org is pretty dead and MSYS2 is really our only path forward.

Again, all I'm asking is to look at the changes. They're not huge. Assume resolveMacro works. I've tested that. The only change I'm worried about is the getVersion for gdb. For some reason we deprecated the LaunchUtil and then never changed the GDBLaunchDelegate to use the recommended one. Why did we leave it?

Doug.

On Fri, Jun 3, 2016 at 1:26 PM, Marc-André Laperle <marc-andre.laperle@xxxxxxxxxxxx> wrote:
I don't think it would be accurate to say CDT would be Linux only without this change. CDT supports MinGW through the MBS. I assume this change was to help setting up PATH for users? People using MinGW/MSYS have been setting the PATH variable manually for a very long time, so there's at least a way to make it work. Of course, it's always nice to make things easier and out-of-the-box for users. In any case, I just thought I'd clarify this statement about CDT being Linux only without this change.

Marc-Andre


On 2016-06-03 12:54 PM, Doug Schaefer wrote:
Our entire MSYS2 story doesn't work without this change. If we want CDT to be Linux only, I guess we can wait. Not sure that's wise though.

On Fri, Jun 3, 2016 at 12:09 PM, Marc Khouzam <marc.khouzam@xxxxxxxxxxxx> wrote:
Hi,

I'm not familiar with the workings of ICdtVariableManager.resolveValue() so I don't know the impact of this change.
Could calling this make existing debug launches in the wild fail?
What is the impact of this bug?

I personally don't feel RC4 is the appropriate time for this.  Can't it wait for 9.1?

Marc

From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Doug Schaefer [cdtdoug@xxxxxxxxx]
Sent: June 2, 2016 10:59 PM
To: CDT General developers list.
Subject: [cdt-dev] More fixes for env vars on launch for msys2

Hey gang,

I'm not sure how my first fix worked. At any rate, found some more weirdness that prevented launching with the MSYS2 toolchain from working. I'd love someone from debug land to take a look at this and make sure I'm not crazy.


Thanks,
Doug


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev



_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev



_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev


Back to the top