That guy has been haunted me since the first time I posted on illumos topic box. It's not for no reasons I said he is toxic.
Btw, the project I'm trying to build is a programming language that use LLVM as the backend. What CMake failed to find is the LLVM Libraries, not the LLVM Toolchain. CMake has no problems finding and use Clang, and the fact is I use GCC to build that project. Don't blame CMake too soon. Let's acknowledge that you are a crazy platform that doesn't follow any conventions in FHS. Even FreeBSD with it weirdness FHS by abusing /usr/local since /usr/local is for locally built stuffs, not binary packages, it's somehow still follow a standard FHS that make CMake has no difficulty finding the needed libraries. You are not! You placed everything all over the places, mixing 32 bit and 64 bit libraries, and you expect CMake to be able to correctly find the libraries? Do you pay CMake developers to work on supporting your platform? Are you contributed patches to CMake to make it correctly pick up the libraries from the mess which is your FHS? No. You didn't do anything. You blamed CMake instead. It's like the CMake developer has the responsibility to support all obscure OS in the world! Even me, the human, don't know where you put the LLVM libraries, let alone CMake! Let's recall that from internet search I know that you used to target 32 bit by default even though your OS is exclusively 64 bit and people has to force it to produce 64 bit binary by -m64! >From mailing list, it seems you removed 32 bit libraries (that makes the wine >users unhappy). If it's the case, why don't you make /usr/lib the default >location for 64 bit libraries? WTF is /usr/lib/64? I'm pretty doubt that you >are fully 64 bit yet. Btw, if Peter Tribble's answer is right, then the LLVM >libraries are not in /usr/lib/64 either. I have personally confirmed that >/usr/lib/64/cmake doesn't contain LLVMConfig.cmake or llvm-config.cmake. I don't want to deal with your crazy platform anymore. I'm currently happy with FreeBSD, where I still need to specify -DCMAKE_PREFIX_PATH, but the FHS is predictable. Aug 1, 2024, 05:31 by udo.grabow...@kit.edu: > On 31/07/2024 23:46, scavenger via openindiana-discuss wrote: > >> You don't know how to use CMake? Please be less toxic for the life to be >> more beautiful. It will help not only you but also the people communicating >> with you feel better! >> > > An interesting approach to blame other people for the failures > of cmake ... cmake is notoriously bad on "other" platforms (that is, > not L/W/M) because it wants to be jack of all trades and fails > miserably, and clearly the whole concept cannot work reliably, even on > a single platform things can vary significantly, and on a platform > like illumos where a couple of compilers (and compiler versions) > and linkers live, it gets easily lost. I always struggle hard with > cmake build systems outside of Linux, and fail in about 50% of cases > because its nearly impossible (or uneconomic) to get the misconceptions > fixed. I now try to avoid packages with a cmake build system. > > If you want to blame people, direct your rants to the cmake developers, > not onto us. > _______________________________________________ > openindiana-discuss mailing list > openindiana-discuss@openindiana.org > https://openindiana.org/mailman/listinfo/openindiana-discuss > _______________________________________________ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
