[LLVMdev] patches for the LLVM cmake build system

[Victor Zverovich]

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>