There is no visible advantage to use `ninja` instead of traditional `make` to build llvm, so no need to bring another (really unusual) dependency... -- `make` is everywhere, and it works pretty fine to build llvm Reproducible: Always
Created attachment 419184 [details, diff] Patch to current llvm-3.7.0-r4.ebuild
There is a visible advantage and you see it when you run the build. And it becomes especially important when you build huge packages like LLVM. Furthermore, the generator setting respects user override. So if you really are a ninja hater, you can set CMAKE_MAKEFILE_GENERATOR and forget about it.
(In reply to Michał Górny from comment #2) > There is a visible advantage and you see it when you run the build. I meant it looks mostly the same (as Makefiles generated by CMake) and nothing else I cant see... > And it > becomes especially important when you build huge packages like LLVM. any particular numbers? all that I can find in google, "Ninja designed w/ speed in mind", but no real benchmarks of it!! ... so I've done my own (using Core i7 4710HQ, 16G RAM, SSD): * for a project which builds 4min 56s by make, Ninja gave me 4min 52s, which is definitely doesn't deserve to stop using GNU make and start to use Ninja... > > Furthermore, the generator setting respects user override. So if you really > are a ninja hater, you can set CMAKE_MAKEFILE_GENERATOR and forget about it. It doesn't work as expected! Setting this variable tries to install `ninja` to me anyway!
(In reply to Alex Turbov from comment #3) > (In reply to Michał Górny from comment #2) > > There is a visible advantage and you see it when you run the build. > > I meant it looks mostly the same (as Makefiles generated by CMake) and > nothing else I cant see... Then please compare verbose build log for both, and tell me which is more useful. Unless you find it extremely useful to see thousands of 'echo' commands, and percentages that don't mean a thing. > > Furthermore, the generator setting respects user override. So if you really > > are a ninja hater, you can set CMAKE_MAKEFILE_GENERATOR and forget about it. > > It doesn't work as expected! Setting this variable tries to install `ninja` > to me anyway! If you use unsupported hacks, you're, well... unsupported. You need to deal with deps etc. on your own. Pro-tip: package.provided. And please do not reopen requests that were explicitly refused. It's inpolite, at the very least.
(In reply to Michał Górny from comment #4) > Then please compare verbose build log for both, and tell me which is more > useful. Unless you find it extremely useful to see thousands of 'echo' > commands, and percentages that don't mean a thing. Ok, I got your point... just a matter of your taste... > > > Furthermore, the generator setting respects user override. So if you really > > > are a ninja hater, you can set CMAKE_MAKEFILE_GENERATOR and forget about it. > > > > It doesn't work as expected! Setting this variable tries to install `ninja` > > to me anyway! > > If you use unsupported hacks, you're, well... unsupported. You need to deal > with deps etc. on your own. Pro-tip: package.provided. No, AFAIK, I don't... maybe you would be so kind as to give me a clue where do you suppose I can use that "hacks"?
(In reply to Alex Turbov from comment #3) > > Furthermore, the generator setting respects user override. So if you really > > are a ninja hater, you can set CMAKE_MAKEFILE_GENERATOR and forget about it. > > It doesn't work as expected! Setting this variable tries to install `ninja` > to me anyway! If setting CMAKE_MAKEFILE_GENERATOR="emake" causes ninja to still get pulled in, that sounds like a bug in cmake-utils.eclass
(In reply to Michael Palimaka (kensington) from comment #6) > If setting CMAKE_MAKEFILE_GENERATOR="emake" causes ninja to still get pulled > in, that sounds like a bug in cmake-utils.eclass Not really a bug in the eclass. DEPEND must be invariant according to PMS; overriding CMAKE_MAKEFILE_GENERATOR in the environment causes DEPEND to change, which violates this constraint. The package manager's behavior is undefined. It sounds like portage continues to use DEPEND from the metadata cache in this situation. It could be argued that eclass behavior should not be affected by the environment. However, it does come in handy for development when you want to quickly override a setting for testing.
I'll just leave it here FYI, https://public.kitware.com/Bug/view.php?id=15968
