clang packaging question

Hello,

clang will be shipped with Fedora's Linux distribution as of version
12, which is scheduled for release in a couple of months.

With that in mind, I have a couple of questions regarding packaging.
Our preliminary packaging has llvm-clang containing the files that are
installed by default, and llvm-clang-analyzer containing files
corresponding to the binary checker release posted on
clang-analyzer.llvm.org.

1. Noting that clang and clang-cc can currently operate without LLVM
installed, would it be better to have the llvm-clang package depend on
llvm or not?
2. The clang binary's emit-llvm mode currently only works if -S is
also supplied; would it eventually automatically invoke the
appropriate LLVM tools (as per the clang-cc examples)? In which case,
the answer to (1) is obvious.
3. Does the Clang team have any preference w.r.t. package naming? e.g.
  -- llvm-clang or just clang
  -- llvm-clang-analyzer, clang-analyzer, or llvm-checker

Thanks,

1. Noting that clang and clang-cc can currently operate without LLVM
installed, would it be better to have the llvm-clang package depend on
llvm or not?

If you're distributing the gold plugin, it would be nice to have once
it works (see below); otherwise, I don't see any need to drag in the
other LLVM tools unless the user requests them, at least for the
moment.

2. The clang binary's emit-llvm mode currently only works if -S is
also supplied; would it eventually automatically invoke the
appropriate LLVM tools (as per the clang-cc examples)? In which case,
the answer to (1) is obvious.

In theory, it should work with the gold plugin
(http://llvm.org/docs/GoldPlugin.html), although I don't think clang
actually passes the right options to the linker at the moment. There
have been discussions of other modes, but nothing definite.

3. Does the Clang team have any preference w.r.t. package naming? e.g.
-- llvm-clang or just clang
-- llvm-clang-analyzer, clang-analyzer, or llvm-checker

I don't have any opinion here.

Are you planning to base the release off of LLVM 2.6? If not, note
that you should uncomment the USE_PRODUCTION_CLANG define in
clang/lib/Driver/Driver.cpp.

-Eli

clang will be shipped with Fedora's Linux distribution as of version
12, which is scheduled for release in a couple of months.

Cool.

Our preliminary packaging has llvm-clang containing the files that are
installed by default, and llvm-clang-analyzer containing files
corresponding to the binary checker release posted on
clang-analyzer.llvm.org.

   make clang-only
   make install-clang

is the path I'd recommend. This builds and installs just clang.

1. Noting that clang and clang-cc can currently operate without LLVM
installed, would it be better to have the llvm-clang package depend on
llvm or not?

Depends upon your needs and desires. If you want clang to be able to be faster moving and not tied directly to llvm, uncoupled is a nice way to develop. If you want them fully coupled, just drop clang into llvm and build both together. Around here, we like them decoupled (for now). If you don't need them decoupled, together results in faster build times, if you also ship llvm bits for some reason.

3. Does the Clang team have any preference w.r.t. package naming? e.g.
-- llvm-clang or just clang
-- llvm-clang-analyzer, clang-analyzer, or llvm-checker

just clang I think is best. The middle one, though Ted might have a better idea.

Depends upon your needs and desires. If you want clang to be able to be
faster moving and not tied directly to llvm, uncoupled is a nice way to
develop. If you want them fully coupled, just drop clang into llvm and
build both together. Around here, we like them decoupled (for now). If you
don't need them decoupled, together results in faster build times, if you
also ship llvm bits for some reason.

We ship the LLVM bits too, but after build, the installed files are
split off into separate subpackages.

3. Does the Clang team have any preference w.r.t. package naming? e.g.
-- llvm-clang or just clang
-- llvm-clang-analyzer, clang-analyzer, or llvm-checker

just clang I think is best. The middle one, though Ted might have a better
idea.

So clang and clang-analyzer, then. Thanks!

1. Noting that clang and clang-cc can currently operate without LLVM
installed, would it be better to have the llvm-clang package depend on
llvm or not?

If you're distributing the gold plugin, it would be nice to have once
it works (see below); otherwise, I don't see any need to drag in the
other LLVM tools unless the user requests them, at least for the
moment.

Ah, OK. I'll have to experiment more with the gold plugin.

2. The clang binary's emit-llvm mode currently only works if -S is
also supplied; would it eventually automatically invoke the
appropriate LLVM tools (as per the clang-cc examples)? In which case,
the answer to (1) is obvious.

My mistake; using '-c' also works, though clang should perhaps use .ll
and .bc extensions, rather than .s and .o? With -c, the bitcode file
generated can then be executed using lli. I guess there is no such
thing as a linked bitcode file anyway.

In theory, it should work with the gold plugin
(http://llvm.org/docs/GoldPlugin.html), although I don't think clang
actually passes the right options to the linker at the moment. There
have been discussions of other modes, but nothing definite.

The Clang documentation does not specifically mention gold, so I'm a
bit unclear on things -- would gold be just another supported linker,
or would it be required?

Fedora currently does not ship gold with its binutils, but if this
would become a requirement, I could ask to have it added.

Are you planning to base the release off of LLVM 2.6? If not, note
that you should uncomment the USE_PRODUCTION_CLANG define in
clang/lib/Driver/Driver.cpp.

Ah, good to know. This define is not in the clang-2.6.tar.gz snapshot
that comes with the LLVM 2.6 prerelease, though -- is this something
that is trunk-specific? Would later prereleases, and the final 2.6,
have this define that then has to be taken out?

Thanks,

In theory, it should work with the gold plugin
(http://llvm.org/docs/GoldPlugin.html), although I don't think clang
actually passes the right options to the linker at the moment. There
have been discussions of other modes, but nothing definite.

The Clang documentation does not specifically mention gold, so I'm a
bit unclear on things -- would gold be just another supported linker,
or would it be required?

Required for linking with -emit-llvm to work properly, otherwise not
required. But it's probably not worth worrying about for the first
release.

Are you planning to base the release off of LLVM 2.6? If not, note
that you should uncomment the USE_PRODUCTION_CLANG define in
clang/lib/Driver/Driver.cpp.

Ah, good to know. This define is not in the clang-2.6.tar.gz snapshot
that comes with the LLVM 2.6 prerelease, though -- is this something
that is trunk-specific? Would later prereleases, and the final 2.6,
have this define that then has to be taken out?

I think it got added after the first prerelease. You don't need to
mess with it if you're working from the 2.6 branch.

-Eli