Page MenuHomePhabricator

[Clang] Implement basic MinGW32 version-independent installation detection
AbandonedPublic

Authored by yaron.keren on Jun 17 2014, 5:25 AM.

Details

Summary

Adds a basic MinGW32 driver to Clang with GCC-version-independent installation detection that enables building using MinGW in non-hardcoded paths.

As there were breaking changes in trunk, the diff submitted is for release 3.4 as I am unable to build trunk with or without it (and therefore unable to test it). At the moment the patch will not, by default, search "C:\MinGW" as was the old behaviour. However, if necessary, implementing it should be trivial.

This implementation does inherit from Generic_GCC. It successfully detects GCC version 4.8.1 on Windows 7 x64 when given a sysroot of "C:\MinGW\x86_64-posix-4.8.1-rev5" (I should emphasise that the "4.8.1" is not derived from the the directory name).

Diff Detail

Event Timeline

CJKay updated this revision to Diff 10494.Jun 17 2014, 5:25 AM
CJKay retitled this revision from to [Clang] Implement basic MinGW32 version-independent installation detection.
CJKay updated this object.
CJKay edited the test plan for this revision. (Show Details)
CJKay added reviewers: compnerd, rnk, yaron.keren.
CJKay set the repository for this revision to rL LLVM.
yaron.keren edited edge metadata.Jun 17 2014, 5:39 AM

The patch must work with trunk to be accepted. The breaking changes are probably MinGW not being an OS anymore but an environment, you can test for it using isWindowsGNUEnvironment().

Have you compared to http://reviews.llvm.org/D3420 by martell/ruben ?

yaron.keren edited edge metadata.Jun 17 2014, 5:40 AM
yaron.keren added a subscriber: Unknown Object (MLST).
CJKay added a comment.EditedJun 17 2014, 5:46 AM

The patch must work with trunk to be accepted. The breaking changes are probably MinGW not being an OS anymore but an environment, you can test for it using isWindowsGNUEnvironment().

Have you compared to http://reviews.llvm.org/D3420 by martell/ruben ?

I'm afraid someone else will have to patch it for release then. I can't get trunk to build at all with or without the patch due to some major changes in the build system that I've been unsuccessful in patching for my system.

I have taken a look at ruben's patch but not extending Generic_GCC causes it to be significantly more complex than it needs to be as most of the logic can be transferred, contrary to what he states. It still uses hardcoded paths whereas this patch uses Generic_GCCs version detection.

When I can get a working trunk build I'll give a shot at updating the patch.

What are the problems with the build system? are you using cmake?

What are the problems with the build system? are you using cmake?

I am. It seems add_{clang,llvm}_library() macros were added, but as of yet the rest of the project has not been updated to use them properly. This results in a lot of CMake policy warnings, and about 98% into the build process, I get missing reference errors inside liblibClang.a when trying to build diagtool.exe. I have so far not had much luck in fixing this for myself, as I am fairly uneducated on the changes introduced, and it doesn't look as if I can temporarily disable building diagtool. I can submit a bug report if you wish, as I can still build release 3.4 smoothly.

You can disable building the tools with -DLLVM_BUILD_TOOLS=OFF on the CMake command line.
More build options: http://llvm.org/docs/CMake.html

I am building LLVM with Visual C++ 2013 routinely and I think one of the build bots does use MinGW.
Which compiler are you using? MinGW? which version?

CJKay added a comment.EditedJun 17 2014, 10:41 AM

You can disable building the tools with -DLLVM_BUILD_TOOLS=OFF on the CMake command line.
More build options: http://llvm.org/docs/CMake.html

I am building LLVM with Visual C++ 2013 routinely and I think one of the build bots does use MinGW.
Which compiler are you using? MinGW? which version?

Edit: build complete.

Updating for trunk is proving difficult, but I will update this thread with the diff when I work around the environment/OS switcharoo.

What is the status on this? It would be really nice to drop the hardcoded paths.

CJKay added a comment.EditedAug 14 2014, 2:49 AM
In D4177#11, @rafael wrote:

What is the status on this? It would be really nice to drop the hardcoded paths.

Sadly, I don't currently have the free time to work on this at the moment. The code that I posted so far needs to be reworked for current trunk but I don't reckon I know enough about LLVM's internals to properly update it either way as there were some fairly substantial changes.
If no progress has been made over the next few months I could perhaps speak to my manager about dedicating some of my time to it, but I've no idea how well that would go down.

yaron.keren commandeered this revision.Jun 30 2015, 10:19 PM
yaron.keren edited reviewers, added: CJKay; removed: yaron.keren.
yaron.keren abandoned this revision.Jun 30 2015, 10:19 PM