Arch Linux

(Copying from http://mailman.archlinux.org/pipermail/aur-general/2009-October/007059.html)

I've uploaded llvm 2.6-1 to [community-testing]. It doesn't include clang, as I believe it should be built as a separate package. I think it's possible to download both llvm and clang tarballs, place clang inside the tools subdirectory and run `make install' from there. We'll need to investigate this possibility.

Testing of the uploaded packages would be appreciated. :)

> It doesn't include clang, as I believe it should be built as a separate package.

Quite possibly. I don't know much about LLVM, but the compilation instructions on their site seemed to indicate that it's best to build both at the same time. This is why I decided to do that, but package the separately. It also seems to suggest that building clang independently is possible.

> I think it's possible to download both llvm and clang tarballs, place clang inside the tools subdirectory and run `make install' from there. We'll need to investigate this possibility.

Uhh, yes, it is... I proved that with the PKGBUILD I posted. Did you look at it at all?

> Uhh, yes, it is... I proved that with the PKGBUILD I posted. Did you look at it at all?

I've looked at two or three PKGBUILDs for llvm/clang (yours included), an ebuild from Gentoo and had a glance at Debian's packages. I'm trying my best to provide great quality packages for something I'm not very familiar with. If you got the impression that I overlooked your PKGBUILD (and the effort you put into it), I apologize, but this is not the case. When I said `make install' I was thinking about the compilation step and not the installation part (I probably should have said `make').

Sorry if I sounded offended or something, it just seemed like you were trying to do something I already did. What's the problem with my method? It does exactly what you said (the compilation step compiles llvm + clang, package_llvm() packages llvm + clang but clang is removed, and package_clang() packages clang only). I looked at a few other build scripts myself, and this seems to be the way everyone's going (apart from the "remove clang" hack I did in package_llvm()). I would only find a way not to install clang along with llvm in package_llvm(). The NO_INSTALL method _should_ work, but it somehow didn't for me, and I didn't really have time to look into it.

I forgot to thank you for the update in my previous comment. I was mostly looking forward to Clang, but I have it locally so I'm happy ;).

I messed around with clang a bit more, and I've decided to go with your way (3 split packages). Also, I found a way to build both llvm and clang, but only install llvm in the package_llvm function; you move the clang directory outside of the llvm root for the `make install' step and bring it back in after that. I compared the package lists and it appears to work.

I need to do some more testing (and grab any fixes from the PKGBUILD that Ranguvar posted on the ML) and then I'll upload 2.6-2 to [community-testing].

New llvm, clang and clang-analyzer packages (2.6-2) will be uploaded to [community-testing] shortly. Thanks to all the people that showed interest and pushed this forward with their ideas and PKGBUILDs. I hope these packages are good to go. :)

Feedback is welcome.

I wrote most of the PKGBUILD that is posted; why is my name stripped out from the credit?
Anyways, here is hopefully the final PKGBUILD from me. It combines stuff from Xilon's new PKGBUILD with clang-analyzer.

Please base any modifications off of my PKGBUILD; it has many small changes that may be hard to spot compared to some of the others floating around here.
I don't do the "remove docs from Make targets", for example, because that also kills the man pages. Instead, I just rm -rf the dir with the PS/PDF/HTML docs.
Also, I fixed the problem where 'scan-build' symlink wasn't properly installed, etc etc.

Does anyone have any reason for doing the "remove libHello transformation"? I took that bit out.


http://pastebin.ca/1650969

foutrelis, my PKGBUILD contains a ton of differences from the one posted here (and even some from the one I posted earlier), please take a look :)

Hi David,

I agree that credit must always be given where it's due. To be clear, your name is listed on both llvm 2.6-1 and the soon-to-be-uploaded 2.6-2 packages that enter [community-testing]. Sebastian's (Xilon) name is also listed in the contributors for other things (like packaging clang-analyzer separately). I know your previous comment was directed at him, but I'm sure that no malice was intended on his part.

Now, regarding the PKGBUILD itself:

- I've purposefully left out flags like --libdir and --sysconfdir because they have no effect, and flags like --disable-expensive-checks and --enable-jit are already disabled and enabled respectively by default, so there's no need to specify them.
- I do not agree with installing clang and then removing its files from the llvm package. The method I described above ("you move the clang directory outside of the llvm root for the `make install' step and bring it back in after that") seems more elegant to me.

Other than that, our PKGBUILDS do not differ much (which is good :3).

I'm not too sure about the LLVMHello shared library either, but I believe it's an example and thus non-important.

2.6-2 packages are being uploaded as I'm writing this, and I would appreciate any feedback about them. :)

s/David/Devin/ # sorry, it's a bit late and me being sick doesn't help

Best wishes, hope you get better soon :) I was sick earlier, but now am fine, so you have my sympathies.

I believe that --libdir and --sysconfdir should be left in: just in case they do have _some_ impact we have not seen (they don't hurt, anyways) and as a reminder to us for each new version of LLVM to check and see if they haven't fixed the problem that they don't work.
As for --disable-expensive-checks and --enable-jit, I left in the former so that people customizing the PKGBUILD would see it, as it's rather useful when enabled for debugging LLVM. I left in --enable-jit becuase the LLVM documentation recommends doing so:
(http://llvm.org/docs/GettingStarted.html#config) "Compile the Just In Time (JIT) compiler functionality. This is not available on all platforms. The default is dependent on platform, so it is best to explicitly enable it if you want it."
Anyways, it shouldn't hurt? Maybe it would be best to leave it out, though.

And yes, I must have missed that, that does seem a more elegant approach :)


Once we nail down the above, I'll take a look at 2.6-2 and critique it :)

> I wrote most of the PKGBUILD that is posted; why is my name stripped out from the credit?

I didn't mean to leave anyone out. I just copied the llvm package in community and started hacking away at it. I looked at the clang-svn[1] package but it didn't really help much. As you see, the PKGBUILDs are different. You weren't mentioned either in so I'm not sure which PKGBUILD you wrote, either way I didn't even look at it. The similarities are probably coincidence (in how many ways can you package something anyway? :P). Sorry though. If our PKGBUILDs are so similar, I would have saved myself a few hours had I seen it.

> - I do not agree with installing clang and then removing its files from the llvm package. The method I described above ("you move the clang directory outside of the llvm root for the `make install' step and bring it back in after that") seems more elegant to me.

Agreed, although even that seems like a bit of a hack. Would it be better to build llvm and clang + clang-analyzer separately? They have separate sources after all.

Thanks for the update. I'm sure there will be some interesting packages coming in to AUR using LLVM :).

http://aur.archlinux.org/packages/clang-svn/clang-svn/PKGBUILD

Oh, okay, I didn't mean to sound as offended as all that xD Sorry.

Here's the changes I would make (and thus have made) to the 2.6-2 PKGBUILD:

1.) It uses sed to not build the docs, which includes PostScript and HTML stuff we don't want. This also kills the man pages,, which is very bad. Instead, we should delete the doc dir after build().
2.) I have a bit in my PKGBUILD that makes it so if a user turns off stripping, the --disable-optimize flag is passed, which disables stripping in the actual build. Makes sense, right?
3.) I have the --disable-debug-runtime and --disable-exensive-checks flags passed to configure. This makes no real difference -- they're both the default -- but it "costs" nothing and it shows the user what flags to enable if they want to catch segfaults and such.
4.) The sed to get rid of RPATH stuff doesn't seem to be right, it doesn't escape the '$'. I dunno if this is truly necessary, but yeah.
5.) You forgot to make clang depend on LLVM :P
6.) I tweaked the pkgdescs a bit.
7.) Added a describing comment here and there.
8.) Other misc. stuff.


I hope you like it and can use it :)
http://pastebin.ca/1651220

1) I didn't kill any men, I swear; I'm innocent! :< (`pacman -Ql llvm | grep share/man' lists lots of man pages)
2) Are you talking about the following line?

[ "$(check_option strip)" = "n" ] && _optimize_flag="--disable-optimize"

If yes, it's already included in 2.6-2. :\

3) That makes sense, though it doesn't warrant uploading another 50 MiB or so. :P (I'll put it in the next package release.)
4) I was a bit confused about that as well. You're most likely right, but it appears to work in the current context. Some interesting test cases are:

[foutrelis@failboat ~]$ echo '$abc' | sed 's:$:b:'
$abcb
[foutrelis@failboat ~]$ echo '$abc' | sed 's:\$:b:'
babc
[foutrelis@failboat ~]$ echo '$abc' | sed 's:$a:b:'
bbc
[foutrelis@failboat ~]$ echo '$abc' | sed 's:\$a:b:'
bbc

5) As far as I'm aware, it doesn't need llvm to operate (Fedora recently removed it from their dependencies, however Gentoo still has it and mentions something about link time optimization [1]). I could be wrong though.
6) I am not a fan of the word "utilizing". Doesn't "using" seem like a better choice?
7) Comments are nice. I'll include them in the next package release.

By the way, why is libelf needed? I couldn't find any mentions it anywhere in the source. Lastly, pkgbase should remain as 'llvm' (it gets set to the same value as the first element of pkgname by default, so we don't need to specify it at all).

Thanks for the feedback.

Cheers.

----
[1] http://gentoo-portage.com/AJAX/Ebuild/97868/View

1.) Really? Never mind then, huh. Well then, it's up for grabs whether the sed or the rm is better.
2.) Durr.
4.) *holds up hand* I'm still noobish at sed.
5.) Wow, really? I thought it would be a hard dep, I thought Clang was built entirely off of LLVM? I don't have any tests to back this up, though, just figured it would be so.
6.) I wiffle-waffled on that, but thought 'utilizing' was nicer than 'using' because 'using' implies just that, using, whereas 'utilizing' sounds more like Clang is not just using LLVM, but is based around it... which I thought was true, until #5?


Basically, I'd really like it if you could base any new PKGBUILD you write off of mine, instead of incoroporating ideas from mine into yours, because there's tons of tiny little things that are different :)

libelf was in another PKGBUILD for llvm before. I *think* it's needed, I *think* I had tried without it and it didn't work. But I'm very possibly wrong :P
As for pkgbase, makes sense. You know more than me about split packages :)

LLVM provides mostly static libraries (.a files) which are basically archives containing objects (.o files). Clang must be compiling those objects files in, so there's no dependency on LLVM during runtime (makes sense for a compiler, I guess).

I did a `diff -upb' of our PKGBUILDs [1] and they seem to do the same things, more or less. I will base future PKGBUILDs off of my current one, because I'm familiar with it and it's more of my "style". I hope you'll agree with my reasoning for this decision. I'll include some wording changes you've made, as well as the extra configure flags that may prove helpful for people customizing the PKGBUILD.

Regarding libelf, I took the subversion repo of llvm and did an `svn log' on it (which turned out to be ~328 thousand lines!) and it's only mentioned in one commit:

8<-------------------------------------------------------------------
r75643 | djg | 2009-07-14 21:06:25 +0300 (Tue, 14 Jul 2009) | 2 lines

LLVM doesn't use libelf. Remove libelf configurey.
8<-------------------------------------------------------------------

So I believe we can safely leave it out of the dependencies.

I'm really enjoying the discussion we're having about LLVM. If no issues with the 2.6-2 packages are reported, I'll move them to [community] in the following days.

Cheers.

----
[1] http://omploader.org/vMm9hag