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
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.

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.


[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

Back to the top