Kenneth Boyd <zaimoni at zaimoni.com> writes: [snip]>> That does not really surprise me about CMake, but then mingw is not a >> primary compiler on Windows, more so is VC++ or Intel, either way a >> bug should be submitted to the CMake devs. > I do not want to troll the CMake devteam, so I will not submit the bug > report without a full-blown patch.The CMake devteam is very responsive about bug reports. They will certainly appreciate your bug report, no patch required.> My internal priority for that CMake patch is low, as I need only minimal > patching to use the autoconf-generated configure script to build LLVM. > Right now it's just llvm.config.in.in that needs patching (the failsafed > GenLibDeps.pl script went in recently); I'll float a proper RFC on > llvm-commit when I actually schedule time to do a non-hackish patch.I'm seeing a failure related to circular library references while building LLVM with CMake and MSYS. This didn't happen on the past. Building with the configure script works, so it seems something related to CMake. Do you have any insight on this? [snip]>> I thought you could >> override things like that with some command line parameters anyway. >> You cannot force it to output mingw files directly? >> > Correct. I know which project type will give the correct file paths > (MSYS), but since I have sh both CMake 2.6.1 and CMake 2.6.2 > categorically refuse to generate the MSYS CMakefile; even the > command-line parameter approach fails.Apart from the circular library references mentioned above, CMake works fine with MSYS for me (well, the generated makefiles doesn't work with parallel make (-j x) but that's another issue). [snip] -- Oscar
Óscar Fuentes wrote:> Kenneth Boyd <zaimoni at zaimoni.com> writes: > > [snip] > >> My internal priority for that CMake patch is low, as I need only minimal >> patching to use the autoconf-generated configure script to build LLVM. >> Right now it's just llvm.config.in.in that needs patching (the failsafed >> GenLibDeps.pl script went in recently); I'll float a proper RFC on >> llvm-commit when I actually schedule time to do a non-hackish patch. >> > > I'm seeing a failure related to circular library references while > building LLVM with CMake and MSYS. This didn't happen on the > past. Building with the configure script works, so it seems something > related to CMake. Do you have any insight on this? >I'll get back on this tonight or tomorrow. * Am I correct in thinking that the CMake process doesn't reference GenLibDeps.pl? * I am seeing desynchronization between the configure-generated Makefiles and the CMakeFile.txt files. [e.g., llc; makefile doesn't have asmprinter, CMakeFile.txt does]. That much I should be able to construct a patch for "blind", if no-one gets to it first. Kenneth
Kenneth Boyd <zaimoni at zaimoni.com> writes:>> I'm seeing a failure related to circular library references while >> building LLVM with CMake and MSYS. This didn't happen on the >> past. Building with the configure script works, so it seems something >> related to CMake. Do you have any insight on this? >> > I'll get back on this tonight or tomorrow.Thanks.> * Am I correct in thinking that the CMake process doesn't reference > GenLibDeps.pl?The LLVM CMake build system generates and uses llvm-config where it is required (MSVC++ can live without it). This means that GenLibDeps.pl is invoked for building llvm-config.> * I am seeing desynchronization between the configure-generated > Makefiles and the CMakeFile.txt files. [e.g., llc; makefile doesn't > have asmprinter, CMakeFile.txt does]. That much I should be able to > construct a patch for "blind", if no-one gets to it first.Maybe there are some such desynchronizations. Please report them and I'll fix them. On this specific case, IIRC, MinGW chokes if asmprinter is not on the list of components. This may be another consequence of the malfunctoning of llvm-config/GenLibDeps.pl on MinGW/MSYS. -- Oscar
Óscar Fuentes wrote:> The CMake devteam is very responsive about bug reports. They will > certainly appreciate your bug report, no patch required. >I still don't think I have enough detail to file a bug report (not sure exactly what they need to know about my system configuration to make it testable). I did go ahead (just now) and ask the main CMake mailing list which files I need to look at to force a working CMake 2.6.2 bootstrap. If I can fix that on my end, I expect to have enough information to file a bug report.> I'm seeing a failure related to circular library references while > building LLVM with CMake and MSYS. This didn't happen on the > past. Building with the configure script works, so it seems something > related to CMake. Do you have any insight on this? >It occurred to me fairly recently that the only modules listed as depending on AsmPrinter in the LibDeps.txt on my end are the __ASMPrinter *.o files. I take it CMake is currently configured to scan *.o files for dependencies to extrapolate, as well as *.a files? Kenneth
Kenneth Boyd <zaimoni at zaimoni.com> writes:>> I'm seeing a failure related to circular library references while >> building LLVM with CMake and MSYS. This didn't happen on the >> past. Building with the configure script works, so it seems something >> related to CMake. Do you have any insight on this? >> > It occurred to me fairly recently that the only modules listed as > depending on AsmPrinter in the LibDeps.txt on my end are the > __ASMPrinter *.o files. I take it CMake is currently configured to scan > *.o files for dependencies to extrapolate, as well as *.a files?CMake does not scan *.o nor *.a files for dependencies. That's GenLibDeps.pl job. As the CMake build system invokes this utility the same way the configure&make build system does, I'm suspecting it is something to do with the options I pass to gcc. I need to match them with those used by make, to produce the same object and library files, and see if this solves the problem with circular dependencies. -- Oscar