Hi Óscar, On 14 March 2010 15:06, Óscar Fuentes <ofv at wanadoo.es> wrote:> Victor Zverovich <victor.zverovich at googlemail.com> writes: > > > Hi llvm-dev, > > > > Attached are two patches for the LLVM cmake build system. > > > > The first one adds static runtimes (MT and MTd) to the list of runtimes > for > > the MSVC build. > > This seems not to be as easy as you put it. It was discussed here > recently: > > From: José Fonseca > Subject: [PATCH]: MSVC build enhancements > Date: Sat, 6 Mar 2010 10:43:50 +0000 > >I've read this thread but what I propose is simpler because this only allows the user to choose static runtime for all configurations (Debug, Release, MinSizeRel and RelWithDebInfo). I understand that it is not ideal because one would normally want MTd for Debug and MT for the rest but that's how it works now for MD as well. This patch doesn't try to solve this issue. But I don't see why static runtime options should be excluded as they are now. It only makes more difficult to build LLVM with a static runtime.> The second one makes it possible to use llvm_config in external projects. > > In this patch I took the liberty of changing the format of > LLVMLibDeps.cmake > > to define a single variable LLVM_LIB_DEPS instead of MSVC_LIB_DEPS_*. > > LLVM_LIB_DEPS contains the list of libraries and dependencies in the > > following form: > > > > set ( LLVM_LIB_DEPS > > * <lib-name> <dependency 1> ... <dependency n> > > ... > > ) > > > > Here '*' is used as a delimiter to specify where each library dependency > > list starts > > > > This allows to get both the list of libraries and dependency information > > from one source. It is done in the explicit_map_components_to_libraries > > function which uses LLVM_LIB_DEPS to populate llvm_libs and > MSVC_LIB_DEPS_* > > if they are not defined thus allowing external use. > > Interesting idea. But this method does not take into account the case > where the user does not build all libraries (i.e. ignores some LLVM > targets). On this scenario your method will take into account all > libraries, including those not built. IMO it is really needed to know > which LLVM libraries were built before resolving dependencies for client > projects, as it actually does for resolving dependencies for the LLVM > tools. I pretend to incorporate this information on a cmake file that is > installed along the rest of LLVM. > >I don't see what is the advantage for the user in the method you describe. In both cases the user will get an error when using library which was not built, right? Why not install LLVMLibDeps.cmake?> _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100317/14cd2c6b/attachment.html>
Victor Zverovich <victor.zverovich at googlemail.com> writes:>> > Attached are two patches for the LLVM cmake build system. >> > >> > The first one adds static runtimes (MT and MTd) to the list of >> > runtimes for the MSVC build. >> >> This seems not to be as easy as you put it. It was discussed here >> recently: >> >> From: José Fonseca >> Subject: [PATCH]: MSVC build enhancements >> Date: Sat, 6 Mar 2010 10:43:50 +0000 >> >> > I've read this thread but what I propose is simpler because this only allows > the user to choose static runtime for all configurations (Debug, Release, > MinSizeRel and RelWithDebInfo). I understand that it is not ideal because > one would normally want MTd for Debug and MT for the rest but that's how it > works now for MD as well. This patch doesn't try to solve this issue. But I > don't see why static runtime options should be excluded as they are now. It > only makes more difficult to build LLVM with a static runtime.If I understand correctly the clarifications given by José on that thread, adding the /MT flag is not enough. You must remove the /MD or /MDd flags from whatever cmake variables where they can be present.>> Interesting idea. But this method does not take into account the case >> where the user does not build all libraries (i.e. ignores some LLVM >> targets). On this scenario your method will take into account all >> libraries, including those not built. IMO it is really needed to know >> which LLVM libraries were built before resolving dependencies for client >> projects, as it actually does for resolving dependencies for the LLVM >> tools. I pretend to incorporate this information on a cmake file that is >> installed along the rest of LLVM. >> >> > I don't see what is the advantage for the user in the method you describe. > In both cases the user will get an error when using library which was not > built, right? Why not install LLVMLibDeps.cmake?LLVMLibDeps.cmake will be installed. It is useful to know which libraries are available. See tools/llc/CMakeLists.txt, for instance. It uses ${LLVM_TARGETS_TO_BUILD} for building the llc tool with support for all targets included on the LLVM build.
On 17 March 2010 19:07, Óscar Fuentes <ofv at wanadoo.es> wrote:> Victor Zverovich <victor.zverovich at googlemail.com> writes: > > >> > Attached are two patches for the LLVM cmake build system. > >> > > >> > The first one adds static runtimes (MT and MTd) to the list of > >> > runtimes for the MSVC build. > >> > >> This seems not to be as easy as you put it. It was discussed here > >> recently: > >> > >> From: José Fonseca > >> Subject: [PATCH]: MSVC build enhancements > >> Date: Sat, 6 Mar 2010 10:43:50 +0000 > >> > >> > > I've read this thread but what I propose is simpler because this only > allows > > the user to choose static runtime for all configurations (Debug, Release, > > MinSizeRel and RelWithDebInfo). I understand that it is not ideal because > > one would normally want MTd for Debug and MT for the rest but that's how > it > > works now for MD as well. This patch doesn't try to solve this issue. But > I > > don't see why static runtime options should be excluded as they are now. > It > > only makes more difficult to build LLVM with a static runtime. > > If I understand correctly the clarifications given by José on that > thread, adding the /MT flag is not enough. You must remove the /MD or > /MDd flags from whatever cmake variables where they can be present. > >I tested it with VS2008 and CMake 2.8 and it works.> >> Interesting idea. But this method does not take into account the case > >> where the user does not build all libraries (i.e. ignores some LLVM > >> targets). On this scenario your method will take into account all > >> libraries, including those not built. IMO it is really needed to know > >> which LLVM libraries were built before resolving dependencies for client > >> projects, as it actually does for resolving dependencies for the LLVM > >> tools. I pretend to incorporate this information on a cmake file that is > >> installed along the rest of LLVM. > >> > >> > > I don't see what is the advantage for the user in the method you > describe. > > In both cases the user will get an error when using library which was not > > built, right? Why not install LLVMLibDeps.cmake? > > LLVMLibDeps.cmake will be installed. It is useful to know which > libraries are available. See tools/llc/CMakeLists.txt, for instance. It > uses ${LLVM_TARGETS_TO_BUILD} for building the llc tool with support for > all targets included on the LLVM build. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100318/1b866daf/attachment.html>