Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] RCP Debugger for Windows?

I think you’ve misinterpreted my concern.

The question I ask myself is what compiler distribution would I support with a commercial version of CDT, I.e. With paid support from users. Not that there is any money to be had there. I just think our users of the CDT deserve to be treated like customers and to build that relationship of trust with them. That gives CDT a good reputation and for those of us who are making commercial versions of CDT, it gives us a great foundation to stand on. And, of course, it’s great for the users since they’re using tools they can trust.

For Linux and Mac, the answer to that question is easy. Linux distros all ship high quality compilers and libraries. Apples’s Xcode command-line tools is the obvious choice for Mac, though the toolchains shipped by Homebrew could also be worthy, though as many have reported, the homebrew gdb has issues with signing.

For Windows, it’s not that obvious. Yes, the equation.com compilers look pretty good. But I have no idea who those people are and whether I can trust they’ll keep up their great work. Qt, is in the same situation as we are and are actually redistributing the w64 mingw compiler, though only 32-bit for some reason. But they also ship support for the last 3 or 4 visual C++ releases. Though the issue with Visual C++ as I’ve mentioned is the lack of a CDT debug story for it. Clang and lldb are under construction for Windows but it’s not in a state yet where we can rely on them. Mingw-w64 with their installer seems to be the best bet at the moment.

And I don’t really care about a *nix environment for builds. I used to, but the Arduino toolchains don’t have a *nix environment so I have to already deal with that. It’s not that big of a challenge. RMDIR /s works just as well as rm –fr. Though, I think the CDT builder should delete the output directory itself on a clean.

I’d feel better if there was an easy way for the user to define their own toolchains so they can integrate whichever toolchain they’ve chosen and we can quickly adapt to it. That will be one of the cornerstones of the CDT 9 build work.

HTH,
Doug.

From: <cdt-dev-bounces@xxxxxxxxxxx> on behalf of kesselhaus <kesselhaus@xxxxxxx>
Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Date: Wednesday, July 22, 2015 at 6:17 PM
To: "cdt-dev@xxxxxxxxxxx" <cdt-dev@xxxxxxxxxxx>
Subject: Re: [cdt-dev] RCP Debugger for Windows?

Hi,

I'm a bit concerned about, how that discussion started and was going into strange directions from my point of view.
GCC which you actually support currently is in my opinion not the problem.
It's not only mingw and cygwin out there. I think, I stated this some time ago already, that e.g. at http://www.equation.com/servlet/equation.cmd?fa=fortran, they provide a GCC distribution of 32bit and 64bit for windows (even latest 5.1 versions and snapshots), and also include GDB and make.

I guess, what your main problem is, is the build environment not being a UNIX shell like, but windows command prompt based.
So, there is no rm -f *.o or similar things, but the internal builder will work quite nicely, and produce the same usable binaries, which can be debugged in CDT.
Therefore, the most critical part here is actually, how to build the beast, not calling the tools or paths or debugging.

The question is always, why you need a UNIX shell like environment on Windows, be it cygwin or mingw.
Maybe we just need other build toolchains, that are more abstracting from the actual OS.
e.g. scons or waf or cmake might be viable solution. But just keeping the UNIX like makefile based MBS build system is problematic.

If you want to switch to VC++ support, is not an option for everybody. Where do you get the compiler from? Is it still distributed by Microsoft separately from Visual Studio in the SDK?
I've heard, it's not included anymore, but I could be wrong.
The other thing with VC++ is, that the compiler does e.g. not support C99. It's C90, maybe they'll put in some C11 in the near future.
I'm not sure, if somebody downloads >500MB of community or express edition is then going to use Eclipse/CDT; my guess is, they are just using VS then.

Regarding the Clang/LLVM, I wonder if they now start to support Windows or not. There have been releases of Clang/LLVM, where either there was no release for Windows, or it was missing major libraries (headers and libs), a point where I always rejected to even look at Clang/LLVM. Without the stdlib, how am I supposed to get a running binary. And then they provide maybe an major release of Clang/LLVM, but minor bugfixes do not provide a binary for windows, whatever the bugfix releases were about (the information is about lacking). Look into the 3.4, 3.5.
A lot of users are not able to build the compiler themself, they want to install the update and that's it. That is like if you might use a Linux Fedora/Suse/Debian/Ubuntu.. or you use Gentoo.

e.g. in my company (Automotive embedded software), we are thinking to change from VC++ based Cantata Unit testing to gcc-based unit testing.
One thing is, that using Jenkins as CI tool, compiling the unit tests with gcc is much easier than with VC++ solutions.
Our toolchain is currently based on makefiles, but we are changing to scons or similar environment.

Regards,
kessel

Am 15.07.2015 um 18:31 schrieb Doug Schaefer:
Interesting. Having said that, I decided to take another look at mingw-64, the good fork of mingw. They actually do have an installer that is packaging up the latest compiler and includes gdb. You can get it here:


It would be cool if CDT could install the toolchain for you...

Doug.


From:cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Doug Schaefer [dschaefer@xxxxxxx]
Sent: Wednesday, July 15, 2015 11:15 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] RCP Debugger for Windows?

I’m pretty concerned about the state of local Windows development anyway. Cygwin messes us up by being to Linux-y with it’s file paths, MinGW has forked with the old one moving too slow and being 32-bit only and the new one not having a consistent packaging mechanism. We should always declare a toolchain we “officially” support but I’m not sure we can do that for Windows at the moment.

Part of me suggests we should abandon the GNU world on Windows, focus on better support for Microsoft’s toolchain. But that’s a lot of work that someone would have to do for free since I don’t see a lot of commercial value there.

Maybe Clang/LLDB will help but it’s not clear how much they are focused on Windows either.

Which is all to bad, I think Windows 10 will start to appeal to engineers again and I don’t see it going away. It’s what most students, hobbyists, game developers, etc. are using. We should try and figure out a good strategy there.

Doug.

From: <cdt-dev-bounces@xxxxxxxxxxx> on behalf of Marc-André Laperle <marc-andre.laperle@xxxxxxxxxxxx>
Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Date: Wednesday, July 15, 2015 at 9:56 AM
To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Subject: Re: [cdt-dev] RCP Debugger for Windows?

Not really. No one asked for it though. Did someone talk to you about it? It's a bit of extra work to set the icons, add a few OS specific plugins and testing. I wasn't sure there was a real demand for it since there is WinDbg already. I can add Windows support easily if people want it (and other OS and architectures).

Marc-Andre


From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Marc Khouzam [marc.khouzam@xxxxxxxxxxxx]
Sent: Wednesday, 15 July 2015 9:08 AM
To: CDT DEV (cdt-dev@xxxxxxxxxxx)
Subject: [cdt-dev] RCP Debugger for Windows?

Hi,

is there a technical reason why we don't provide the new RCP Debugger for Windows?

Thanks

Marc


_______________________________________________
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