I'm hoping to revive the LLD standalone CMake build. I'm new to this build but it looks like it borrowed code from an old version of compiler-rt, which I did some work on last year. Like compiler-rt, I'd like to get the LLD build up running with only CMAKE_PREFIX_PATH instead of defining custom variables like LLD_PATH_TO_LLVM_BUILD and LLD_PATH_TO_LLVM_SOURCE. Any objection to that? Also, two files ELFLinkingContext.cpp and MachOLinkingContext.cpp include a private header from the LLVM source tree, "llvm/Config/config.h" to get access to HAVE_CXXABI_H. Can the dependency on HAVE_CXXABI_H be removed? If no, mind if I add a config.h.cmake to LLD's "include/lld/Config"? Thanks, Greg
On Thu, Jan 8, 2015 at 11:38 AM, Greg Fitzgerald <garious at gmail.com> wrote:> I'm hoping to revive the LLD standalone CMake build. I'm new to this > build but it looks like it borrowed code from an old version of > compiler-rt, which I did some work on last year. Like compiler-rt, > I'd like to get the LLD build up running with only CMAKE_PREFIX_PATH > instead of defining custom variables like LLD_PATH_TO_LLVM_BUILD and > LLD_PATH_TO_LLVM_SOURCE. Any objection to that? >I think I don't have enough knowledge on the CMake build system to comment on this. If no one objects and things keep working, that'd be fine to me.> Also, two files ELFLinkingContext.cpp and MachOLinkingContext.cpp > include a private header from the LLVM source tree, > "llvm/Config/config.h" to get access to HAVE_CXXABI_H. Can the > dependency on HAVE_CXXABI_H be removed? If no, mind if I add a > config.h.cmake to LLD's "include/lld/Config"?I believe that dependency cannot be removed since the code really needs to know whether cxxabi.h is available or not. Feel free to add config.h.cmake to include/lld/Config. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150109/23964d11/attachment.html>
On Wed, Jan 7, 2015 at 6:38 PM, Greg Fitzgerald <garious at gmail.com> wrote:> I'm hoping to revive the LLD standalone CMake build.Why? It adds complexity and cost to everyone who has to touch the build system. Note that even if you're willing to "maintain" the standalone build, that doesn't *really* fix the problem. Lots of folks will need to make changes to the build system, and these types of different supported usage scenarios make these much harder to think about, enact, and test. Having to build and test and install using 3 or 4 different combinations of standalone and not standalone is a complete nightmare. I'm pretty strongly opposed to more standalone build support unless developers on the project have really serious problems with IDE scaling. Honestly, if we could fix the IDE scaling, I'd rip all of the standalone build support out of all of our CMake builds. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150108/bd462a8c/attachment.html>
>> I'm hoping to revive the LLD standalone CMake build. > Why?Maintaining the standalone build allows us to purge dependencies on internals of the LLVM build. In this case, it spotted a dependency on a private header. It also points out the spots where the exported CMake libraries depend on global variables set by LLVM's CMakeLists.txt. -Greg
On Thu, Jan 8, 2015 at 2:29 PM, Chandler Carruth <chandlerc at gmail.com> wrote:> > On Wed, Jan 7, 2015 at 6:38 PM, Greg Fitzgerald <garious at gmail.com> wrote: > >> I'm hoping to revive the LLD standalone CMake build. > > > Why? > > It adds complexity and cost to everyone who has to touch the build system. > > Note that even if you're willing to "maintain" the standalone build, that > doesn't *really* fix the problem. Lots of folks will need to make changes > to the build system, and these types of different supported usage scenarios > make these much harder to think about, enact, and test. > > Having to build and test and install using 3 or 4 different combinations > of standalone and not standalone is a complete nightmare. I'm pretty > strongly opposed to more standalone build support unless developers on the > project have really serious problems with IDE scaling. >I doubt IDE scaling would be an issue in this particular scenario. LLD is so small relative to LLVM that it shouldn't cause a noticeable burden for the IDE. -- Sean Silva> Honestly, if we could fix the IDE scaling, I'd rip all of the standalone > build support out of all of our CMake builds. > > _______________________________________________ > 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/20150108/c7bc0000/attachment.html>
On Wed, Jan 7, 2015 at 6:38 PM, Greg Fitzgerald <garious at gmail.com> wrote:> I'm hoping to revive the LLD standalone CMake build. I'm new to this > build but it looks like it borrowed code from an old version of > compiler-rt, which I did some work on last year. Like compiler-rt, > I'd like to get the LLD build up running with only CMAKE_PREFIX_PATH > instead of defining custom variables like LLD_PATH_TO_LLVM_BUILD and > LLD_PATH_TO_LLVM_SOURCE. Any objection to that? > > Also, two files ELFLinkingContext.cpp and MachOLinkingContext.cpp > include a private header from the LLVM source tree, > "llvm/Config/config.h" to get access to HAVE_CXXABI_H. Can the > dependency on HAVE_CXXABI_H be removed? If no, mind if I add a > config.h.cmake to LLD's "include/lld/Config"? >I personally would be opposed to adding configure machinery to LLD's build. It is just duplicating the machinery already in LLVM. -- Sean Silva> > Thanks, > Greg > _______________________________________________ > 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/20150108/c856dcb5/attachment.html>
How do you feel about adding LLD to the LLVM repo? Could it follow the same path as the integrated assembler? That is, Clang keeps it off by default for each architecture until it's ready for prime time. -Greg On Thu, Jan 8, 2015 at 3:31 PM, Sean Silva <chisophugis at gmail.com> wrote:> > > On Wed, Jan 7, 2015 at 6:38 PM, Greg Fitzgerald <garious at gmail.com> wrote: >> >> I'm hoping to revive the LLD standalone CMake build. I'm new to this >> build but it looks like it borrowed code from an old version of >> compiler-rt, which I did some work on last year. Like compiler-rt, >> I'd like to get the LLD build up running with only CMAKE_PREFIX_PATH >> instead of defining custom variables like LLD_PATH_TO_LLVM_BUILD and >> LLD_PATH_TO_LLVM_SOURCE. Any objection to that? >> >> Also, two files ELFLinkingContext.cpp and MachOLinkingContext.cpp >> include a private header from the LLVM source tree, >> "llvm/Config/config.h" to get access to HAVE_CXXABI_H. Can the >> dependency on HAVE_CXXABI_H be removed? If no, mind if I add a >> config.h.cmake to LLD's "include/lld/Config"? > > > I personally would be opposed to adding configure machinery to LLD's build. > It is just duplicating the machinery already in LLVM. > > -- Sean Silva > >> >> >> Thanks, >> Greg >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >
On Wed, Jan 7, 2015 at 6:38 PM, Greg Fitzgerald <garious at gmail.com> wrote:> I'm hoping to revive the LLD standalone CMake build. I'm new to this > build but it looks like it borrowed code from an old version of > compiler-rt, which I did some work on last year. Like compiler-rt, > I'd like to get the LLD build up running with only CMAKE_PREFIX_PATH > instead of defining custom variables like LLD_PATH_TO_LLVM_BUILD and > LLD_PATH_TO_LLVM_SOURCE. Any objection to that? > > Also, two files ELFLinkingContext.cpp and MachOLinkingContext.cpp > include a private header from the LLVM source tree, > "llvm/Config/config.h" to get access to HAVE_CXXABI_H. Can the > dependency on HAVE_CXXABI_H be removed? If no, mind if I add a > config.h.cmake to LLD's "include/lld/Config"? > > Thanks, > GregHaving the stand alone build is a pretty big obstacle to build system changes, so it's not just a maintenance problem. I'd rather we didn't support it. - Michael Spencer