Problem with libomp (was supertux)

[Ken Cunningham]

> On Dec 5, 2020, at 10:18 AM, Christopher Jones <jonesc at hep.phy.cam.ac.uk> wrote:
> 
> Hi,
> 
>> On 5 Dec 2020, at 5:20 pm, Eric Borisch <eborisch at macports.org <mailto:eborisch at macports.org>> wrote:
>> 
>> It's part of the LLVM project, and can be built at the same time (-DLLVM_ENABLE_PROJECTS=openmp)as other tools; I think losing OpenMP support for MP's clang by default is a step backwards, but most of the google results for "clang openmp mac" point you to homebrew anyway, so perhaps it doesn't matter.
> 
> No one is suggestion removing support for it, just a different way of packaging. To be honest having openmp as a port external to the LLVM ports has never made complete sense to me.
> 
> Currently the way the LLVM suite of ports are built is a bit peculiar and frankly a bit of a relic from SVN days and doesn’t use the LLVM_ENABLE_PROJECTS option to enable components. I believe Ken has looked into using this to simplify the builds, which I think would be good, and then enabling it would be a lot simpler than it currently is. Doing this for all the current LLVM versions is not really practical but perhaps for a future release (maybe an update to 11) we should move to this way of building thing, and then for that version remove the external libomp port dep. and just build it as part of the LLVM port itself.
> 
> Chris


LLVM has two methods for specifying what you want built. The older method is to put things as subfolders (either “projects” or “tool”) of the llvm folder. That is what Jeremy set up, and that is what all the patches, reinplaces, tweaking, python rewriting, destrooting, etc is set up to do now.

The new method is to use the “monorepo” build with everything on the same level, and then you LLVM_ENABLE_PROJECTS what you you want to build.

I had that working a year ago, and showed Chris then.

The problem is not so much the patches — those are an hour to fix — or the reinplaces, etc — longer maybe, but still just legwork.

The problem is how to fracture up the installation of the LLVM subports the way we want them to be. For example, we want to install LLVM alone, without anything else — that’s easy. We want to install only clang, and nothing else. That’s harder — I don’t think there is an available target to do that — I have looked for it, and you can’t just install clang. You always get llvm too. And etc.

So perhaps we might be able to  LLVM_ENABLE_PROJECTS for the things we want to build, and then maybe go into the subfolders inside the build folder and run the destroot command from in that subfolder (kinda like what we do now, to be honest) and maybe that would install only what we need, and not the rest.

And that is my next project, because without doing  LLVM_ENABLE_PROJECTS we will never be able to do a full bootstrap build, which we should do (build clang makes -> throwaway clang makes -> real clang we install).

However, THAT project is DOA until we come to some conclusion about how to fix the years-old MacPorts ncurses problem that prevents any MODULES from being used EVER — so until we decide how to fix that, we can never do a bootstrap build anyway, and the rest is really moot.

So I set up the symlink system to use the monorepo to replicate the llvm subfolder build method, which is working nicely, as you can see, and made adding flang trivial. It would also make adding libomp trivial , but Eric has been doing such a stellar job of that I just saw no need to change it.

Until recently when we had a build failure, which turned out, in the end, for now to be trivial to fix.

So we’re good for another few years, until the next crisis. 

And I’ll move our llvm / etc builds to the  LLVM_ENABLE_PROJECTS method, rewrite all the patches, rewrite all the reinplaces, and figure out the new method of doing partial destrooting — but in the end it will make absolutely not the slightest bit of different to anyone, as the installed products will be identical.

Ken






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20201205/1d64eaee/attachment-0001.htm>