|
Hi kessel,
I don't think we should necessarily abandon GCC and GDB on
Windows but there is a need for
supporting the Visual Studio toolchain for several reasons:
1. Some large projects were written for Visual C++ compiler and
moving to GCC is not trivial
2. Even if they could move to GCC, a lot of libraries are
incompatible with the compiled binaries. I have in mind all the
libraries provided by Microsoft such as DirectX
which are troublesome (if not impossible?) to make it work
with GCC compiled binaries. I'm just speaking from personal
experience so correct me if I'm wrong.
More comments below.
On 7/22/2015 6:17 PM, kesselhaus wrote:
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.
There is MinGW (original), Cygwin, MinGW-64,
MinGW2 and the Equation one (maybe more?). Which one should CDT
focus on? So far, it has been a best effort to make them all work,
depending on what users report (Bugzilla, forums). I think this
will probably still be the same approach in the future (best
effort). I personally test things with MinGW (mingw-get installer)
on occasion.
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.
I don' think the main challenge for GCC/GDB on
Windows is the shell but rather compatibility with libraries,
existing code base support, etc. The rm bug can be worked around
multiple ways (the internal builder being one of them).
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.
I don't think people would choose VS over Eclipse because of just
download size. At least, I hope not! I personally used Eclipse
alongside a full VS 2010 and VS2008 for years because I preferred
programming in Eclipse. I don't think it would be that much to ask
to download the toolchain as part of VS community edition or
Windows SDK. Also, on Mac, you used to have to download the whole
Xcode to get the command line tools (there's a command line way
now) and I think people were OK with that. It's also possible that
Microsoft will release command line tools as a separate download
in the future, stranger things have happened!
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.
I see they release Clang binaries for Windows
now. I think the idea is to have it compatible with the VC++
runtime so that's what you would link against that to get standard
libraries, right?
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.
You can use nmake, cmake and others to use CL as
the compiler instead of using solutions.
I don't think this needs to be a GCC/GDB vs Visual Studio
discussion. We can keep "supporting" GCC and GDB on Windows as a
best effort, as we always have. But there are a lot of other
popular tools out there that need to be more smoothly integrated
so that users can adopt CDT. In any case, I'm not aware of anyone
working on CDT that need to support Windows "officially" so I'm
not sure how much is going to be done in this area.
Regards,
Marc-Andre
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.
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.
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
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
_______________________________________________
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
|
