<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Sorry I’m a little late to this thread.</div><div class=""><br class=""></div>There has been some discussion about using CMake to generate shared libraries. Since I’ve done some patches in this area recently I thought I’d take a minute to explain the current state of things.<div class=""><br class=""></div><div class="">Historically LLVM’s CMake build system has been able to produce shared libraries for each of the llvm static libraries. My patch (<span style="font-family: 'Helvetica Neue';" class="">r220490) added the llvm-shlib tool to the CMake build system. You can now set LLVM_BUILD_LLVM_DYLIB=On on the CMake command line to generate a single libLLVM.dylib with a default set of LLVM libraries included.</span></div><div class=""><font face="Helvetica Neue" class=""><br class=""></font></div><div class=""><font face="Helvetica Neue" class="">Tom, I’m really curious if this is close to meeting your needs. I’m guessing we probably need to add the version number to the library. Anything else?</font></div><div class=""><font face="Helvetica Neue" class=""><br class=""></font></div><div class=""><font face="Helvetica Neue" class="">James, you commented that you like multiple so files because it allows you to pick and choose which bits you need. With the new llvm-shlib in CMake you can specify which components you want included in the LLVM dylib by setting </font>LLVM_DYLIB_COMPONENTS to a semicolon delimited list of LLVM components.</div><div class=""><br class=""></div><div class=""> I looked at compiler-rt a few months back so I might be able to shed a little bit of light into what needs to be fixed in compiler-rt for us. The complication for compiler-rt is that you need to build it for your targets rather than your host, so it immediately becomes a cross-compilation problem. The current CMake configs for compiler-rt actually don’t treat it as cross-compilation, they just try to override the build settings. I think the correct solution (at least for Darwin) is going to be to refactor compiler-rt to actually be cross-configured for each architecture.</div><div class=""><br class=""></div><div class="">My CMake-foo is nowhere near master-level, so I’m a bit fuzzy on some of the details, but CMake has this notion of exported targets, and I think compiler-rt should really just generate a bunch of exported targets that get slurped into a host llvm/clang CMake build. I know this is getting a bit off topic, but if anyone wants to talk more about this feel free to email me or grab me on IRC.</div><div class=""><br class=""></div><div class="">-Chris</div><div class=""><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Nov 3, 2014, at 10:29 AM, Eric Christopher <<a href="mailto:echristo@gmail.com" class="">echristo@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class=""><br class=""><div class="gmail_quote">On Mon Nov 03 2014 at 9:36:45 AM Tom Stellard <<a href="mailto:tom@stellard.net" class="">tom@stellard.net</a>> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Oct 31, 2014 at 11:19:22PM +0000, Eric Christopher wrote:<br class="">
> On Fri Oct 31 2014 at 3:11:22 PM Tom Stellard <<a href="mailto:tom@stellard.net" target="_blank" class="">tom@stellard.net</a>> wrote:<br class="">
><br class="">
> > Hi,<br class="">
> ><br class="">
> > I would like to propose deprecating the autoconf build system at some<br class="">
> > point in the future. Maintaining two build systems is a hassle not<br class="">
> > only for this project, but also for other projects that use LLVM<br class="">
> > and have to deal with the slight differences in output between the two<br class="">
> > build systems.<br class="">
> ><br class="">
> > It seems like most people are using CMake at this point, so my questions<br class="">
> > to the community are:<br class="">
> ><br class="">
> > - Is there any technical reason why the remaining autoconf users can't<br class="">
> > switch<br class="">
> > to CMake?<br class="">
> ><br class="">
> ><br class="">
> I think Bob was the lead on keeping the autoconf system last year when this<br class="">
> came up, there is a PR somewhere in the system about the blocking things<br class="">
> that need to work in cmake to get it to happen. I don't know where we are<br class="">
> on that list or what features people still need.<br class="">
<br class="">
Was this the PR: <a href="http://www.llvm.org/bugs/show_bug.cgi?id=15732" target="_blank" class="">http://www.llvm.org/bugs/show_<u class=""></u>bug.cgi?id=15732</a> ?<br class="">
<br class=""></blockquote><div class=""><br class=""></div><div class="">Looks like it yes.</div><div class=""><br class=""></div><div class="">-eric</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-Tom<br class="">
<br class="">
><br class="">
> Personally I still use the autoconf system, but am willing to remove it if<br class="">
> we can get to a single system, but all of the requirements need to be<br class="">
> handled first.<br class="">
><br class="">
> -eric<br class="">
><br class="">
><br class="">
> > For example, I personally use automake, and the only reason I don't<br class="">
> > use CMake is because it doesn't produce a single shared object<br class="">
> > (e.g. <a href="http://libllvm-3.6.0svn.so/" target="_blank" class="">libLLVM-3.6.0svn.so</a>).<br class="">
> ><br class="">
> > - What is a reasonable timeframe to allow the remaining autoconf users<br class="">
> > a chance to migrate to CMake?<br class="">
> ><br class="">
> > Thanks,<br class="">
> > Tom<br class="">
> > ______________________________<u class=""></u>_________________<br class="">
> > LLVM Developers mailing list<br class="">
> > <a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank" class="">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu/" target="_blank" class="">http://llvm.cs.uiuc.edu</a><br class="">
> > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank" class="">http://lists.cs.uiuc.edu/<u class=""></u>mailman/listinfo/llvmdev</a><br class="">
> ><br class="">
</blockquote></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:LLVMdev@cs.uiuc.edu" class="">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" class="">http://llvm.cs.uiuc.edu</a><br class=""><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br class=""></div></blockquote></div><br class=""></div></div></body></html>