<div class="gmail_quote">On Mon, Jul 25, 2011 at 7:18 PM, Óscar Fuentes <span dir="ltr"><<a href="mailto:ofv@wanadoo.es">ofv@wanadoo.es</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> writes:<br>
<br>
>> I'm not sure I get this. Previous to your change, the LLVM library<br>
>> (LLVMX86CodeGen, for instance) had LLVMX86CodeGen_TableGen as a<br>
>> dependency (plus the tablegen source files) and its sublibraries<br>
>> (LLVMX86AsmPrinter, ...) had LLVMX86CodeGen as a dependency.<br>
><br>
> This is source of the confusion. The sublibraries no longer (in many cases)<br>
> depend on LLVMX86CodeGen; specifically MCTargetDesc actively avoids such a<br>
> dependency.<br>
<br>
</div>This is tangential. What I'm trying to say is that the sublibrary is not<br>
built until the top library finishes building, which means that<br>
tablegenning is done. If the sublibrary references symbols defined by<br>
the top library (or the tablegenned files) that's a different topic.<br></blockquote><div><br></div><div>I'm not sure what platform your observe this behavior, but I don't observe it on Linux. I specifically observe the opposing behavior: subdirectories which do not depend on the libraries in the parent directory are started in parallel. This is one of the advantage of CMake; the builds are highly parallel because of this eager descent into subdirectories.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">>> Somehow<br>
>> this didn't work. So why do we need add_public_tablegen_target at all?<br>
>> The sublibraries, by depending on LLVMX86CodeGen, should not start<br>
>> building until after LLVMX86CodeGen is created, which means that the<br>
>> tablegenning is finished too.<br>
><br>
> See above. The dependency that previously existed no longer does. Thus the<br>
> need for a specific one for the only actual sharing between these two: the<br>
> tablegen files.<br>
<br>
</div>This means an optimization for parallel builds, but doesn't make the<br>
build any more robust.</blockquote><div><br></div><div>I specifically, repeatedly saw the tablegen actions fail to be performed prior to the build and analysis of the subdirectory, so I do in fact find it makes it more robust... I'm sorry if you can't reproduce this, but I did several times, and confirmed with other CMake users.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">The problem with explicitly stating the dependency on every sub-library<br>
is that the writer must decide if the dependency actually exists or not<br>
(and keep the decission up to date as changes are made to the<br>
libraries.) And he has a lot of room for making a mistake. A failed<br>
dependency on this scenario is, essentially, a heisenbug. Personally, I<br>
prefer a global conservative rule.<br></blockquote><div><br></div><div>I don't really follow either of these paths of reasoning.</div><div><br></div><div>First, I do expect authors of code to actively think about and maintain the dependencies of their code. LLVM has actually paid a dear price for not doing this, see Evans heroic work to re-separate the MC and Target layers. Developers are not left without tools here: the build should actually break if they forget to update the dependencies. I would be very interested in tightening this up so that the build *always* breaks when dependencies are mis-specified rather than merely becoming unreliable.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">BTW, possibly not related but the build is failing with:<br></blockquote><div><br></div>
<div>This looks like a missing dependency in MSP430Desc. I can look into it.</div><div><br></div><div>I'd like to point out however that all of our "automatic" management of dependencies didn't help here; we still have failures and still have to debug them by hand. Given that, its hard for me to argue that they are saving us from all of the manual work of maintaining dependencies.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Linking CXX executable ../../bin/llvm-mc<br>
../../lib/libLLVMMSP430Desc.a(MSP430MCTargetDesc.cpp.o): In function `createMSP430MCInstPrinter(llvm::Target const&, unsigned int, llvm::MCAsmInfo const&)':<br>
MSP430MCTargetDesc.cpp:(.text+0x18d): undefined reference to `vtable for llvm::MSP430InstPrinter'<br>
../../lib/libLLVMMipsDesc.a(MipsMCTargetDesc.cpp.o): In function `createMipsMCInstPrinter(llvm::Target const&, unsigned int, llvm::MCAsmInfo const&)':<br>
MipsMCTargetDesc.cpp:(.text+0x421): undefined reference to `vtable for llvm::MipsInstPrinter'<br>
../../lib/libLLVMPowerPCDesc.a(PPCMCTargetDesc.cpp.o): In function `createPPCMCInstPrinter(llvm::Target const&, unsigned int, llvm::MCAsmInfo const&)':<br>
PPCMCTargetDesc.cpp:(.text+0x330): undefined reference to `vtable for llvm::PPCInstPrinter'<br>
../../lib/libLLVMARMDesc.a(ARMMCTargetDesc.cpp.o): In function `createARMMCInstPrinter(llvm::Target const&, unsigned int, llvm::MCAsmInfo const&)':<br>
ARMMCTargetDesc.cpp:(.text+0x32d): undefined reference to `vtable for llvm::ARMInstPrinter'<br>
../../lib/libLLVMMBlazeDesc.a(MBlazeMCTargetDesc.cpp.o): In function `createMBlazeMCInstPrinter(llvm::Target const&, unsigned int, llvm::MCAsmInfo const&)':<br>
MBlazeMCTargetDesc.cpp:(.text+0x2ad): undefined reference to `vtable for llvm::MBlazeInstPrinter'<br>
collect2: ld returned 1 exit status<br>
make[2]: *** [bin/llvm-mc] Error 1<br>
make[1]: *** [tools/llvm-mc/CMakeFiles/llvm-mc.dir/all] Error 2<br>
make[1]: *** Waiting for unfinished jobs....<br>
</blockquote></div><br>