<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 11/06/2012 01:52 AM, M.E. O'Neill
wrote:<br>
</div>
<blockquote
cite="mid:4FCE3BAE-1576-461D-B053-767AE1AFB852@cs.hmc.edu"
type="cite">
<pre wrap="">If you want to build the LLVM core, or Clang, there are great build instructions on the website, but as we go out to other parts of the system (e.g., libc++, libc++abi, and compiler_rt), parts that I'd argue you still really *need* to use Clang to its fullest, we end up in a ghetto of patchy platform support and incomplete information that severely limits the number of people using them.
For example, if you want to use the latest cool -fcatch-undefined-behavior functionality in Clang, you need compiler_rt, but the build instructions in the "Get it and get involved!" section of compiler-rt.llvm.org are wrong. They just don't work (wrong directory paths, missing dependencies for cmake). They also suggest that you need cmake, when in fact there is a "working" Makefile. But if you make it that far, you discover that actually some of the code for -fcatch-undefined-behavior is defined to be Linux only, even though the author thinks it would "probably work" on other platforms. (It does, if you can figure out how to make the build system build it.)
Another example is libc++ and libc++abi. If their respective webpages are to be believed, they only work on OS X. Yet a quick perusal of the libc++ source reveals that it *is* intended to build on Linux (and likely builds on FreeBSD, too). But while it can be done, there are all sorts of traps and gotchas for those trying to build on Linux (e.g., the whole choose-a-workable C++ ABI issue; e.g., by default std::uncaught_exception() calls abort() -- PR13669). None of these aspects are documented in a clear way, leaving people to try to glean what they can from blog posts and inconclusive mailing list threads.
Sometimes I hear excuses like, "Oh, I don't have a Linux box to test on", but these seem weak at best. Virtual Machines are easy to make. And if a developer lacks the skills or motivation to make a VM, they could perhaps ask here for volunteers to help, thereby making a friend who can help them test on other platforms besides their own.
I keep thinking these things will change by themselves as the project matures, but they haven't yet, and at this point, I'm wondering what it's going to take. Don't we *want* people to use libc++ on Linux? Don't we want interested people to play with -fcatch-undefined-behavior on their Macs? Because as it stands now, these parts of the clang world are accessible only to a small group of cognoscenti.
LLDB gives us a glimpse of how these subprojects can do better; it has detailed build instructions for both Linux and OS X, but only if you drill down to a subpage, which some people might not bother to do because the main page for LLDB claims that the only platforms known to work are Darwin-derived ones.
</pre>
</blockquote>
And yet the build instructions are indeed not for a system set up
with cmake, but for the old automake system. Half the projects build
cleanly with automake, the other half are more mature with cmake.
The answer we get is pretty figure it out on your own and once you
do submit it for review.<br>
<br>
<blockquote
cite="mid:4FCE3BAE-1576-461D-B053-767AE1AFB852@cs.hmc.edu"
type="cite">
<pre wrap="">
It would be wonderful if we could work out a fix for this situation and implement it. To my mind, the obvious solution would be to declare some set of platforms (e.g., OS X, iOS, x86 Linux, and FreeBSD) to be supported by the project, and make it so that all key subprojects support these platforms unless there is a compelling reason to do otherwise.
Thoughts anyone...?</pre>
</blockquote>
<br>
What you list seems like a minimum and should be fully tested,
top-to-bottom. It seems Apple and Google have vested interests in
Darwin [OS X and iOS] and Linux, respectively, so these two
platforms [even the generic x86_64 for Linux] should work for both
cmake and the automake approaches. They both have billions invested
in this being solid for both of their respective hardware kernels
they have chosen in the embedded space, never mind Apple directly in
the consumer desktop/laptop/workstation space with x86_64.<br>
<br>
FreeBSD has committed thoroughly with LLVM/Clang being the default
on their trunk. Debian has FreeBSD in-tree for their entire
repository, It stands to reason both FreeBSD and Debian Linux can
get all the major projects to work with both cmake and automake.<br>
<br>
Argonne Labs [Hal Finkel], to Dave at CRAY and other in more
specialized areas clearly make sure what major projects they use
work intimately with their own aims.<br>
<br>
I thought the discussion on cmake vs. automake was settled business
but it is clear that in order for LLVM/Clang and the power of
LLDB/Compiler-RT/Libc++ [libc++abi]/ not to forget Dragonegg that
all these projects would be well served with more than just bone
generic examples of running cmake ../trunk/llvm; make or
../trunk/llvm/configure; make while leaving all the real power on
how to fine tune your builds up to hunting down reading through
thousands of mail postings and filtering out the noise on how these
optimizations apply best and in which domains.<br>
<br>
Documentation on building all the projects and how to fine tune them
seems to be an obvious launchpad for engineers who get paid well in
the first place to see this project a success, not to mention third
party app developers won't waste everyone's time asking the same
question over and over again if a solid and current FAQ with
detailed examples were publicly available.<br>
<br>
For instance,<br>
<br>
The pros/cons of going shared-libraries versus static and what
reason Debian Linux has for producing one monolithic shared-library
when one goes to compile say OpenShading Language from trunk only
having to find out by trial and error the necessary .so files to
include in Larry's cmake LLVM_LIBRARY variable when testing against
LLVM/Clang trunk and how to best automate Deb build files from trunk
for /usr/local install or /opt deb installs without disrupting
/usr/lib/, /usr/bin for Debian's own would be a nice reference back
to Debian for instance.<br>
<br>
Reading through tens of thousands of mail posts with absolutely no
archived categorization is another problem I don't think any
mailgroup has ever solved because there is no pre-defined tagging
system in subject lines for people to work with as best to later
allow for producing useful FAQ solutions.<br>
<br>
There is no NeXTAnswers and this place certainly could use one. Of
course, I had to write some of those NeXTAnswers and the amount of
perl script and hoops we had in-house at NeXT to produce them is a
huge commitment.<br>
<br>
- Marc<br>
<br>
<blockquote
cite="mid:4FCE3BAE-1576-461D-B053-767AE1AFB852@cs.hmc.edu"
type="cite">
<pre wrap="">
M.E.O.
_______________________________________________
cfe-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a>
</pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
Marc J. Driftmeyer<br>
Email :: <a href="mailto:mjd@reanimality.com">mjd@reanimality.com</a><br>
Web :: <a href="http://www.reanimality.com">http://www.reanimality.com</a><br>
Cell :: (509) 435-5212
</div>
</body>
</html>