<div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">On Tue, Nov 4, 2014 at 10:56 AM, Chris Bieneman <span dir="ltr"><<a href="mailto:beanz@apple.com" target="_blank">beanz@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Sorry I’m a little late to this thread.</div><div><br></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><br></div><div>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'">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><font face="Helvetica Neue"><br></font></div><div><font face="Helvetica Neue">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><font face="Helvetica Neue"><br></font></div><div><font face="Helvetica Neue">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><br></div><div> 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></blockquote><div><br></div><div>That is correct. I think the only reasonable way to improve CMake build system for compiler-rt would be to:</div><div>1) have a simple build rules in compiler-rt itself, w/o any architecture/target detection, and</div><div>2) make Clang create multiple compiler-rt builds, one for each architecture we're targeting, and make all these builds use just-built Clang as a host compiler.</div><div>There are initial attempts to achieve this, checked in tools/clang/runtime/CMakeLists.txt, but I never got to finishing and enforcing this, even on Linux. I hope to find a time and work on it</div><div>soon, but feel free to reach out to me if you want to give it a shot.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>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><span class="HOEnZb"><font color="#888888"><div><br></div><div>-Chris</div></font></span><div><div class="h5"><div><div><br></div><div><div><blockquote type="cite"><div>On Nov 3, 2014, at 10:29 AM, Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>> wrote:</div><br><div><br><br><div class="gmail_quote">On Mon Nov 03 2014 at 9:36:45 AM Tom Stellard <<a href="mailto:tom@stellard.net" target="_blank">tom@stellard.net</a>> wrote:<br><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>
> On Fri Oct 31 2014 at 3:11:22 PM Tom Stellard <<a href="mailto:tom@stellard.net" target="_blank">tom@stellard.net</a>> wrote:<br>
><br>
> > Hi,<br>
> ><br>
> > I would like to propose deprecating the autoconf build system at some<br>
> > point in the future.  Maintaining two build systems is a hassle not<br>
> > only for this project, but also for other projects that use LLVM<br>
> > and have to deal with the slight differences in output between the two<br>
> > build systems.<br>
> ><br>
> > It seems like most people are using CMake at this point, so my questions<br>
> > to the community are:<br>
> ><br>
> > - Is there any technical reason why the remaining autoconf users can't<br>
> > switch<br>
> >   to CMake?<br>
> ><br>
> ><br>
> I think Bob was the lead on keeping the autoconf system last year when this<br>
> came up, there is a PR somewhere in the system about the blocking things<br>
> that need to work in cmake to get it to happen. I don't know where we are<br>
> on that list or what features people still need.<br>
<br>
Was this the PR: <a href="http://www.llvm.org/bugs/show_bug.cgi?id=15732" target="_blank">http://www.llvm.org/bugs/show_<u></u>bug.cgi?id=15732</a> ?<br>
<br></blockquote><div><br></div><div>Looks like it yes.</div><div><br></div><div>-eric</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-Tom<br>
<br>
><br>
> Personally I still use the autoconf system, but am willing to remove it if<br>
> we can get to a single system, but all of the requirements need to be<br>
> handled first.<br>
><br>
> -eric<br>
><br>
><br>
> > For example, I personally use automake, and the only reason I don't<br>
> > use CMake is because it doesn't produce a single shared object<br>
> > (e.g. <a href="http://libllvm-3.6.0svn.so/" target="_blank">libLLVM-3.6.0svn.so</a>).<br>
> ><br>
> > - What is a reasonable timeframe to allow the remaining autoconf users<br>
> >   a chance to migrate to CMake?<br>
> ><br>
> > Thanks,<br>
> > Tom<br>
> > ______________________________<u></u>_________________<br>
> > LLVM Developers mailing list<br>
> > <a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu/" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvmdev</a><br>
> ><br>
</blockquote></div>
_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br></div></blockquote></div><br></div></div></div></div></div><br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Alexey Samsonov<br><a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a></div></div>
</div></div>