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

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
>

Daniel Dunbar <daniel at zuster.org> writes:
> My proposal makes it relatively easy for a motivated engineer to
> generate "clean" Xcode projects for LLVM.
"Relatively easy..." famous last words :-)

And how is that different from fixing the cmake Xcode generator?

On Fri, Oct 28, 2011 at 1:32 PM, Óscar Fuentes <ofv at wanadoo.es>
wrote:
> Daniel Dunbar <daniel at zuster.org> writes:
>
>> My proposal makes it relatively easy for a motivated engineer to
>> generate "clean" Xcode projects for LLVM.
>
> "Relatively easy..." famous last words :-)
I already have most of it implemented.
> And how is that different from fixing the cmake Xcode generator?
As I said before, it is much harder to generate good projects from a
generic specification, vs. a custom solution for a particular project.

 - Daniel

On 28 Oct 2011, at 18:26, Daniel Dunbar wrote:
> On Fri, Oct 28, 2011 at 9:56 AM, Óscar Fuentes <ofv at wanadoo.es>
wrote:
>> 
>> 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.
Couldn't a similarly motivated engineer work on greatly improving the
"clean" Xcode projects for cmake in general?

My personal main experience of a similar system is 'boost::build', or
bjam, the build system used for the C++ boost libraries.

This has slowly grown in scope, and I find completely unusable. It makes simple
using boost, or configuring it slightly non-standardly, almost impossible
without asking on IRC or mailing lists. bjam is the sole reason I have not
submitted significant code to boost.

Do not underestimate the benefit of hundreds of webpages written about CMake and
make, detailing their nastier features. Where will your system's nastier
features be documented?

Sorry to sound negative, but I really don't want to have to learn yet
another build system.

One point which I didn't find answered, for casual developers.

I currently do a bit of bug-finding on clang and libc++. All I am interested in
is statements around the complexity of:

CXX=g++4-.6 ./configure --prefix=/llvm --enable-expensive-checks; make -j8; make
install

Will that change at all?

Chris

On Fri, Oct 28, 2011 at 2:12 PM, Christopher Jefferson
<chris at bubblescope.net> wrote:
>
> On 28 Oct 2011, at 18:26, Daniel Dunbar wrote:
>
>> On Fri, Oct 28, 2011 at 9:56 AM, Óscar Fuentes <ofv at
wanadoo.es> wrote:
>>>
>>> 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.
>
> Couldn't a similarly motivated engineer work on greatly improving the
"clean" Xcode projects for cmake in general?
>
> My personal main experience of a similar system is 'boost::build',
or bjam, the build system used for the C++ boost libraries.
>
> This has slowly grown in scope, and I find completely unusable. It makes
simple using boost, or configuring it slightly non-standardly, almost impossible
without asking on IRC or mailing lists. bjam is the sole reason I have not
submitted significant code to boost.
>
> Do not underestimate the benefit of hundreds of webpages written about
CMake and make, detailing their nastier features. Where will your system's
nastier features be documented?
>
> Sorry to sound negative, but I really don't want to have to learn yet
another build system.
You don't. Nothing about what I am proposing changes how you build LLVM.
> One point which I didn't find answered, for casual developers.
See my original post, at the bottom.
>
> I currently do a bit of bug-finding on clang and libc++. All I am
interested in is statements around the complexity of:
>
> CXX=g++4-.6 ./configure --prefix=/llvm --enable-expensive-checks; make -j8;
make install
>
> Will that change at all?
No.

 - Daniel
>
> Chris