<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hello everyone<br>
<br>
Vedant, thanks for bringing this to my attention. From my work on
LLDB, I agree with all your points.<br>
<br>
<blockquote type="cite">I think it's very valuable that we have one
shared build system.</blockquote>
Most of us don't want to spend their time on build system tasks,
right? Supporting a second build system in-tree will inevitably
increase our amount of attention on it. We should be pragmatic and
not jump on new developments easily.<br>
<br>
<blockquote type="cite">If you'd like to check in GN files, my
strong preference would be to accompany that with a plan to phase
cmake out. <br>
</blockquote>
So, would it be a good idea to phase out CMake? I rarely meet people
who are happy with CMake, but I think the bar is still very high,
because:<br>
<br>
* The community developed a collective understanding of CMake with
all it's strengths and pitfalls. With GN most of us had to learn a
new language.<br>
* There is a lot of valuable documentation and tutorials about LLVM
and CMake. It will take time and effort for GN to catch up.<br>
* CMake is the de-facto standard for private and cross-corporation
C++ projects (and rising [1]).<br>
* Kitware is not a stakeholder in LLVM and CMake not tailored to
anyone's specific needs.<br>
<br>
[1] Rank 6 fastest growing languages on GitHub:
<a class="moz-txt-link-freetext" href="https://octoverse.github.com/projects">https://octoverse.github.com/projects</a><br>
<br>
<blockquote type="cite">lldb has two build systems (xcodebuild &
cmake). I suppose opinions differ on whether that works well.
Speaking for myself, having two build systems has been a massive
source of frustration. I regularly see commits which break one of
the two systems because of course they do.</blockquote>
+1 and it's been the same for previous projects I worked on. Is
there a good example where multiple build systems actually coexist
well?<br>
<br>
<blockquote type="cite">Replicating complex bits of build system
logic also is a chore</blockquote>
Yes, it needs knowledge of the pitfalls for both of them + runnable
setups for the various configurations.<br>
Speaking for myself, it takes a lot of time and mood.<br>
<br>
<br>
<div class="moz-cite-prefix">Am 31.10.18 um 23:10 schrieb Nicolai
Hähnle via llvm-dev:<br>
</div>
<blockquote type="cite">On 31.10.18 19:18, Nico Weber via llvm-dev
wrote:
<br>
<blockquote type="cite">If having a BUILD.gn file in every
directory being confusing is a concern, GN has the concept of a
"secondary tree" so that all GN files could be below
llvm/gn/tree/{llvm,clang,lld,...}.
</blockquote>
So maintain it in a separate repository.
</blockquote>
This seems very reasonable as long as GN is not adopted as the one
an only.<br>
Also it's the best way to make sure it's fully maintained by GN
users.<br>
<br>
<br>
Am 01.11.18 um 00:28 schrieb Zachary Turner via llvm-dev:
<blockquote type="cite">One thing to think about is that generated
IDE projects from CMake are less than ideal. In fact I actually
made a post about this a few weeks ago.</blockquote>
Note that IDE vendors are working on direct CMake support as well,
e.g:<br>
* VS2017 & Qt Creator:
<a class="moz-txt-link-freetext" href="https://blog.kitware.com/cmake-e-server-improves-visual-studio-and-qt-creator-ides/">https://blog.kitware.com/cmake-e-server-improves-visual-studio-and-qt-creator-ides/</a><br>
* CLion: <a class="moz-txt-link-freetext" href="https://www.jetbrains.com/help/clion/project-models.html">https://www.jetbrains.com/help/clion/project-models.html</a><br>
<br>
Best<br>
Stefan<br>
<br>
<br>
<div class="moz-cite-prefix">Am 01.11.18 um 01:22 schrieb Vedant
Kumar via cfe-dev:<br>
</div>
<blockquote type="cite"
cite="mid:645EC321-8F3A-4F54-8652-007C3333D3E5@apple.com">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
Hi all,
<div class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On Oct 31, 2018, at 11:18 AM, Nico Weber via
llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org"
class="" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div class="">Hi,</div>
<div class=""><br class="">
</div>
<div class="">first things first: If you're
happy with cmake, you can stop reading now.
Nobody is proposing that LLVM moves off
cmake, and nobody is proposing anything
that's causing people using cmake more work.</div>
<div class=""><br class="">
</div>
<div class="">At the LLVM conference, I gave a
lightning talk [1] about using GN [2] to
build LLVM and clang. cmake is great for
many use cases, but in my opinion local
day-to-day development isn't one of them. So
I wrote GN build files for LLVM and clang,
enough to make `ninja check-llvm check-clang
check-lld` build everything needed for these
three test suites and that all tests pass.
This works on Linux, Mac, Win hosts
targeting X86, ARM, AArch64. You can see
them at [3].</div>
<div class=""><br class="">
</div>
<div class="">I had been worried that it would
be a lot of work to keep the build files up
to date, but I've been using this for all my
LLVM/clang/lld development the last 8
months, and it turned out to not be a big
problem -- LLVM's build files don't change
very often, and GN build files are a
pleasure to work with in my opinion.</div>
<div class=""><br class="">
</div>
<div class="">I gave the lightning talk just
to talk about my personal workflow, but
there was a lot of interest. We had a
roundtable on the next day, and about 20
people said they'd be interested in using
this for their development too. The main
request was that the .gn files are checked
in upstream, so that we can collaborate on
keeping them working. Two to three orgs even
said they'd be interested in moving their
buildbots to GN.</div>
<div class=""><br class="">
As mentioned at the top, the intention here
is not to replace cmake, only to offer an
opt-in alternative for people who are
interested in it. Keeping the GN build going
would be the responsibility of people using
it, not of the general LLVM community. If
this fails to find use and bitrots, we can
easily remove it again.</div>
<div class=""><br class="">
Are there any concerns with checking in GN
files? I've put some initial docs for the GN
build at <a
href="https://reviews.llvm.org/D53944"
class="" moz-do-not-send="true">https://reviews.llvm.org/D53944</a>
; it describes what the GN build is and is
not, what its advantages are (speed and
easier configurability), and some points
about the philosophy behind the LLVM GN
build.</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>I think it's very valuable that we have one shared build
system. If you'd like to check in GN files, my strong
preference would be to accompany that with a plan to phase
cmake out. </div>
<div><br class="">
</div>
<div>I really don't mean to be flippant here -- I'm in awe of
the work you've already done to set up GN files, and I know
transitioning away from cmake would be a massive amount of
work. Hear me out :)</div>
<div><br class="">
</div>
<div>My perspective comes from having worked on lldb for a
while. lldb has two build systems (xcodebuild & cmake).
I suppose opinions differ on whether that works well.
Speaking for myself, having two build systems has been a
massive source of frustration. I regularly see commits which
break one of the two systems because of course they do. No
one wants to test their commit a second time against a build
system they don't really use. Replicating complex bits of
build system logic also is a chore -- I've CC'd Stefan who
might be able to say more about that.</div>
<div><br class="">
</div>
<div>My concern is that introducing gn files into llvm will
cause a bit of a fracture. If the policy is that cmake users
don't have to worry about breaking the gn build, I think gn
users would be less inclined to fix the cmake build. If most
developers decide to switch to gn, that would leave cmake
adopters with a higher (possibly unmanageable) maintenance
burden. It's also confusing for new users, as they already
have a lot of different ways of checking out and building.</div>
<div><br class="">
</div>
<div>I know your plan is to have the maintenance burden of gn
files placed on gn users, and that you haven't experienced
an unmanageable number of breaks over the past 8 months. In
lldb (a lower volume project), I actually do think the
constant build breaks are hard to manage. And I'm just not
sure the temptation to only update gn files could be
resisted, as "works in my build system" tends to shut down
conversations. I'm worried the same thing would happen in
llvm.</div>
<div><br class="">
</div>
<div>best,</div>
<div>vedant</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div class=""><br class="">
</div>
<div class="">If folks are generally ok with
GN files living in-tree, I'll start sending
patches for gradually adding gn files
through the regular review process.</div>
<div class=""><br class="">
</div>
<div class="">If having a BUILD.gn file in
every directory being confusing is a
concern, GN has the concept of a "secondary
tree" so that all GN files could be below
llvm/gn/tree/{llvm,clang,lld,...}.</div>
<div dir="ltr" class=""><br class="">
</div>
<div class="">Cheers,</div>
<div class="">Nico</div>
<div dir="ltr" class=""><br class="">
</div>
<div dir="ltr" class="">1: <a
href="https://llvm.org/devmtg/2018-10/talk-abstracts.html#lt2"
class="" moz-do-not-send="true">https://llvm.org/devmtg/2018-10/talk-abstracts.html#lt2</a></div>
<div dir="ltr" class="">2: <a
href="https://gn.googlesource.com/gn"
class="" moz-do-not-send="true">https://gn.googlesource.com/gn</a>
, <a href="https://is.gd/gn_intro" class=""
moz-do-not-send="true">https://is.gd/gn_intro</a></div>
<div dir="ltr" class="">3: <a
href="https://github.com/llvm-project/llvm-project-20170507/compare/master...nico:gn"
class="" moz-do-not-send="true">https://github.com/llvm-project/llvm-project-20170507/compare/master...nico:gn</a>
, click "Files Changed" to see the GN files.</div>
</div>
</div>
</div>
</div>
</div>
</div>
_______________________________________________<br
class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" class=""
moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br
class="">
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br
class="">
</div>
</blockquote>
</div>
<br class="">
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
cfe-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>