Mondada Gabriele <g.mondada at etel.ch> writes:> I just moved to the CMake solution. By the way, the generated libs > haven't the same names.Which ones? The only difference is that we now generate .lib files where .obj were generated on the past, and require a parameter to be passed to the linker for including them on the final executable.> In my opinion, we have to choose one way and remove the other one. If > it helps, you can put in the win32 directory the result of CMake,On the release tarball? It seems a good idea (as far as someone volunteers to do the work) but someone mentioned on this thread that the project files generated with CMake contains absolute paths.> or add a script that generate this win32 directory with cmake.The amount of work saved by such script would be almost nil, and it can cause problems on setups with more than one compiler installed. -- Oscar
> > I just moved to the CMake solution. By the way, the generated libs > > haven't the same names. > > Which ones? The only difference is that we now generate .lib files > where > .obj were generated on the past, and require a parameter to be passed > to > the linker for including them on the final executable.I was linking with VMCore.lib support.lib System.lib Analysis.lib CodeGen.lib Target.lib Transforms.lib and I'm now linking with LLVMVMCore.lib LLVMScalarOpts.lib LLVMSelectionDAG.lib LLVMSupport.lib LLVMSystem.lib LLVMAnalysis.lib LLVMCodeGen.lib LLVMTarget.lib LLVMTransformUtils.lib LLVMAsmPrinter.lib> > In my opinion, we have to choose one way and remove the other one. If > > it helps, you can put in the win32 directory the result of CMake, > > On the release tarball? It seems a good idea (as far as someone > volunteers to do the work) but someone mentioned on this thread that > the > project files generated with CMake contains absolute paths.Right, I just look inside the .vcproj files generated by CMake and paths are absolute, even by using the command line version of cmake and by specifying relative paths.
Mondada Gabriele <g.mondada at etel.ch> writes:>> > I just moved to the CMake solution. By the way, the generated libs >> > haven't the same names. >> >> Which ones? The only difference is that we now generate .lib files >> where .obj were generated on the past, and require a parameter to be >> passed to the linker for including them on the final executable. > > I was linking with VMCore.lib support.lib System.lib Analysis.lib > CodeGen.lib Target.lib Transforms.lib > and I'm now linking with > LLVMVMCore.lib LLVMScalarOpts.lib LLVMSelectionDAG.lib LLVMSupport.lib > LLVMSystem.lib LLVMAnalysis.lib LLVMCodeGen.lib LLVMTarget.lib > LLVMTransformUtils.lib LLVMAsmPrinter.libI forgot that. Please note that the LLVM CMake build generator works for VS, MinGW, Linux, OS/X... The same library names are used across all platforms (plus platform-dependent prefixes/suffixes). The best part of this is that a single CMake specification for your compiler would work on all platforms LLVM supports with almost no changes. -- Oscar