llvm dev - Oct 2011 - [LLVMdev] [cfe-dev] RFC: Upcoming Build System Changes

On Fri, Oct 28, 2011 at 3:54 AM, Óscar Fuentes <ofv at wanadoo.es> wrote:
> Anyways, if you wish to avoid duplicating info on both Makefile and
> CMakeLists.txt there is a simple solution: read and parse the Makefile
> from the corresponding CMakeLists.txt. For instance, if you put the
> library dependencies on the Makefile like this:
>
> LLVMLIBDEPS := foo zoo bar
>
> obtaining that info from the CMakeLists.txt and generating the cmake
> library dependencies is very simple, nor even you have to put anything
> new on all those CMakeLists.txt, just modify one of the macros that are
> (indirectly) called from each CMakeLists.txt.
>
>
While eliminating duplication is one of the goals I see in this build system
change, I think the more important ones are a) simplifying the build files
and b) making the build faster.

Adding CMake code (I agree it's a terrible scripting language) to parse
Makefiles will make the build slower and more complicated.

-----

I'm not really a stakeholder, but I agree with Chandler, it's worth
investigating simplifying LLVM's CMake files before making Yet Another build
system generator if you haven't already.  That may not solve the problems
associated with the bad XCode project generation, though.

OTOH, LLVM seems to have invented many of it's own tools (lit, tablegen,
filecheck) and they seem to have worked out great.  I wish our test suite
for DynamoRIO had a tool as flexible as FileCheck.  :(

Reid
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20111028/f1a6039c/attachment.html>

Reid Kleckner <reid.kleckner at gmail.com> writes:
> While eliminating duplication is one of the goals I see in this build
system
> change, I think the more important ones are a) simplifying the build files
> and b) making the build faster.
The "build files" are the Makefiles, right? And Dan's proposal
will not
make the cmake build any faster. So those goals are orthogonal to the
cmake build.
> Adding CMake code (I agree it's a terrible scripting language) to parse
> Makefiles will make the build slower and more complicated.
Wrong! :-) Adding that feature is a few lines of code (orders of
magnitude less than the system proposed by Dan) which are executed only
at generation-time, i.e. when cmake has to regenerate the
makefiles/project-files because a file was added/removed, etc. It adds
nothing at build time and you will need a stopwatch to notice the
difference at generation time.
> I'm not really a stakeholder, but I agree with Chandler, it's worth
> investigating simplifying LLVM's CMake files before making Yet Another
build
> system generator if you haven't already.  That may not solve the
problems
> associated with the bad XCode project generation, though.
You guys are mixing several things on the discussion. What Dan proposed
makes no difference for Xcode. If it speeds up the Makefile-based build
(something I doubt) that's good, but it is unnecessary for that system
to fiddle with the cmake build as long as cmake can deal with the
changes on its own.

Keep in mind that, if Dan goes ahead his plans, tinkering on any build
system would require knowledge of both of them plus the python
scripts. That's adding complexity, quite a lot.

[snip]

On Fri, Oct 28, 2011 at 9:56 AM, Óscar Fuentes <ofv at wanadoo.es>
wrote:
> Reid Kleckner <reid.kleckner at gmail.com> writes:
<snip>
> Keep in mind that, if Dan goes ahead his plans, tinkering on any build
> system would require knowledge of both of them plus the python
> scripts. That's adding complexity, quite a lot.
This argument might make sense if you already know CMake.

However, most developers do not and it is much easier to learn Python
than CMake.

We currently have about 7k lines of CMake code in LLVM/Clang. My
python scripts to deal with my proposal are significantly smaller than
that.

 - Daniel
>
> [snip]
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>

On Fri, Oct 28, 2011 at 9:56 AM, Óscar Fuentes <ofv at wanadoo.es>
wrote:
> Reid Kleckner <reid.kleckner at gmail.com> writes:
>
>> While eliminating duplication is one of the goals I see in this build
system
>> change, I think the more important ones are a) simplifying the build
files
>> and b) making the build faster.
>
> The "build files" are the Makefiles, right? And Dan's
proposal will not
> make the cmake build any faster. So those goals are orthogonal to the
> cmake build.
>
>> Adding CMake code (I agree it's a terrible scripting language) to
parse
>> Makefiles will make the build slower and more complicated.
>
> Wrong! :-) Adding that feature is a few lines of code (orders of
> magnitude less than the system proposed by Dan) which are executed only
> at generation-time, i.e. when cmake has to regenerate the
> makefiles/project-files because a file was added/removed, etc. It adds
> nothing at build time and you will need a stopwatch to notice the
> difference at generation time.
>
>> I'm not really a stakeholder, but I agree with Chandler, it's
worth
>> investigating simplifying LLVM's CMake files before making Yet
Another build
>> system generator if you haven't already.  That may not solve the
problems
>> associated with the bad XCode project generation, though.
>
> You guys are mixing several things on the discussion. What Dan proposed
> makes no difference for Xcode. If it speeds up the Makefile-based build
> (something I doubt) that's good, but it is unnecessary for that system
> to fiddle with the cmake build as long as cmake can deal with the
> changes on its own.
My proposal makes it relatively easy for a motivated engineer to
generate "clean" Xcode projects for LLVM.

 - Daniel
>
> Keep in mind that, if Dan goes ahead his plans, tinkering on any build
> system would require knowledge of both of them plus the python
> scripts. That's adding complexity, quite a lot.
>
> [snip]
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>

On Fri, Oct 28, 2011 at 9:56 AM, Óscar Fuentes <ofv at wanadoo.es>
wrote:
> Reid Kleckner <reid.kleckner at gmail.com> writes:
>
>> While eliminating duplication is one of the goals I see in this build
system
>> change, I think the more important ones are a) simplifying the build
files
>> and b) making the build faster.
>
> The "build files" are the Makefiles, right? And Dan's
proposal will not
> make the cmake build any faster. So those goals are orthogonal to the
> cmake build.
>
>> Adding CMake code (I agree it's a terrible scripting language) to
parse
>> Makefiles will make the build slower and more complicated.
>
> Wrong! :-) Adding that feature is a few lines of code (orders of
> magnitude less than the system proposed by Dan) which are executed only
> at generation-time, i.e. when cmake has to regenerate the
> makefiles/project-files because a file was added/removed, etc. It adds
> nothing at build time and you will need a stopwatch to notice the
> difference at generation time.
This is not what Reid was talking about (as I understood him). He was
referring to what we would need to do if we wanted to keep the
existing Makefiles working, but centralize the information inside
CMake.

 - Daniel
>
>> I'm not really a stakeholder, but I agree with Chandler, it's
worth
>> investigating simplifying LLVM's CMake files before making Yet
Another build
>> system generator if you haven't already.  That may not solve the
problems
>> associated with the bad XCode project generation, though.
>
> You guys are mixing several things on the discussion. What Dan proposed
> makes no difference for Xcode. If it speeds up the Makefile-based build
> (something I doubt) that's good, but it is unnecessary for that system
> to fiddle with the cmake build as long as cmake can deal with the
> changes on its own.
>
> Keep in mind that, if Dan goes ahead his plans, tinkering on any build
> system would require knowledge of both of them plus the python
> scripts. That's adding complexity, quite a lot.
>
> [snip]
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>