Packaging LLVM

[Ranguvar-2]

Hello,

I see that the package 'llvm' is in [community], is orphaned, and is
out-of-date.  I've spent considerable time working on packaging LLVM and its
add-ons, the Clang C-family compiler front-end and the GCC frontend.
Therefore, I'd like to help package LLVM.
I already wrote a PKGBUILD for v2.6 of LLVM (the package we have is v2.5),
and it also has a lot of fixes and niceties.

I'd like to discuss how best to proceed with LLVM -- whether Clang should be
included in the llvm package or as an alternate package of LLVM and Clang,
'llvm-clang', stuff like that.

In fact, what may work best is if llvm could be dropped into the AUR, where
I will then adopt it and update it (and potentially add 'llvm-clang' and
such as is decided), and then if a TU wants it in [community] (which would
make sense), it can be adopted by a TU.

Thanks!
        Devin Cofer, aka Ranguvar

[Tobias Kieslich]

Hi,

I'm using LLVM myself, especially with clang and the static analyzer. I
would like to see LLVM and clang separated, however the clang version is
only available via svn and that depends on LLVM-svn very much.

So I think it's better to build a general LLVM package with the gcc-
frontend for stable development and a conflicting/providing llvm-clang
package from svn. All that must be tested, if it works with
otherllvm-realated packages (the llvm based D-compiler comes to mind)

-T

On Mon, 26 Oct 2009, Ranguvar wrote:

> Hello,
>
> I see that the package 'llvm' is in [community], is orphaned, and is
> out-of-date.  I've spent considerable time working on packaging LLVM and its
> add-ons, the Clang C-family compiler front-end and the GCC frontend.
> Therefore, I'd like to help package LLVM.
> I already wrote a PKGBUILD for v2.6 of LLVM (the package we have is v2.5),
> and it also has a lot of fixes and niceties.
>
> I'd like to discuss how best to proceed with LLVM -- whether Clang should be
> included in the llvm package or as an alternate package of LLVM and Clang,
> 'llvm-clang', stuff like that.
>
> In fact, what may work best is if llvm could be dropped into the AUR, where
> I will then adopt it and update it (and potentially add 'llvm-clang' and
> such as is decided), and then if a TU wants it in [community] (which would
> make sense), it can be adopted by a TU.
>
> Thanks!
>         Devin Cofer, aka Ranguvar

[Ranguvar-2]

It appears that Clang is available as an actual release this time around, so
no need for SVN :)  See this: http://llvm.org/releases/download.html#2.6

As for the splitting of the packages, it will be either difficult or
impossible to separate LLVM and Clang, is the problem.  Plus, I anticipate
Clang being _far_ smaller than the GCC frontend -- it shouldn't be much
trouble to include it in the LLVM package.
The problem is that Clang must be built using the source from LLVM, and
seems to need to be compiled with LLVM.  That would suggest that to offer
Clang separately from LLVM, the two would have to be manually ripped apart
-- I can build LLVM, and I can build LLVM+Clang, but not just Clang.
That may be subject to change, of course, I may have missed something.

So, the route I like would be to put LLVM+Clang in the llvm package, and
offer the GCC frontend as a separate optdep.

On Mon, Oct 26, 2009 at 6:03 PM, Tobias Kieslich <tobias@...>wrote:

> Hi,
>
> I'm using LLVM myself, especially with clang and the static analyzer. I
> would like to see LLVM and clang separated, however the clang version is
> only available via svn and that depends on LLVM-svn very much.
>
> So I think it's better to build a general LLVM package with the gcc-
> frontend for stable development and a conflicting/providing llvm-clang
> package from svn. All that must be tested, if it works with
> otherllvm-realated packages (the llvm based D-compiler comes to mind)
>
> -T
>
> On Mon, 26 Oct 2009, Ranguvar wrote:
>
> > Hello,
> >
> > I see that the package 'llvm' is in [community], is orphaned, and is
> > out-of-date.  I've spent considerable time working on packaging LLVM and
> its
> > add-ons, the Clang C-family compiler front-end and the GCC frontend.
> > Therefore, I'd like to help package LLVM.
> > I already wrote a PKGBUILD for v2.6 of LLVM (the package we have is
> v2.5),
> > and it also has a lot of fixes and niceties.
> >
> > I'd like to discuss how best to proceed with LLVM -- whether Clang should
> be
> > included in the llvm package or as an alternate package of LLVM and
> Clang,
> > 'llvm-clang', stuff like that.
> >
> > In fact, what may work best is if llvm could be dropped into the AUR,
> where
> > I will then adopt it and update it (and potentially add 'llvm-clang' and
> > such as is decided), and then if a TU wants it in [community] (which
> would
> > make sense), it can be adopted by a TU.
> >
> > Thanks!
> >         Devin Cofer, aka Ranguvar
>

[Tobias Kieslich]

On Mon, 26 Oct 2009, Ranguvar wrote:

> It appears that Clang is available as an actual release this time around, so
> no need for SVN :)  See this: http://llvm.org/releases/download.html#2.6
Oh huebsch! ... or sweet in English ...
>
> As for the splitting of the packages, it will be either difficult or
> impossible to separate LLVM and Clang, is the problem.  Plus, I anticipate
> Clang being _far_ smaller than the GCC frontend -- it shouldn't be much
> trouble to include it in the LLVM package.
I think you are wrong on both assumptions, just the clang_cc binary is
16 MB the combined libClang* come to 24MB so it is smaller than gcc I
think but still significant. I do think, however, that there can be
seperate packages, I have a pretty good idea which files are to put
where.

You are right that they will have to be build at the same time but we
can split packages now from the same PKGBUILD file. Not that I would
have done it yet but the pacman folks are working on it and AFAIK it's
complete.

The ugly part so far is, I haven't found a way to put clang_cc somewhere
else than /usr/libexec which would be deprecated in Archlinux. If you
move it around the static analyer barfs ...

> The problem is that Clang must be built using the source from LLVM, and
> seems to need to be compiled with LLVM.  That would suggest that to offer
> Clang separately from LLVM, the two would have to be manually ripped apart
> -- I can build LLVM, and I can build LLVM+Clang, but not just Clang.
> That may be subject to change, of course, I may have missed something.
>
> So, the route I like would be to put LLVM+Clang in the llvm package, and
> offer the GCC frontend as a separate optdep.

   -T

[Ranguvar-2]

Very well, I'll make a prototype PKGBUILD that has sections for each install
and then post it here, good luck :)

I do think it odd though that Clang would be larger than GCC, I guess we'll
have to see.

On Mon, Oct 26, 2009 at 6:39 PM, Tobias Kieslich <tobias@...>wrote:

> On Mon, 26 Oct 2009, Ranguvar wrote:
>
> > It appears that Clang is available as an actual release this time around,
> so
> > no need for SVN :)  See this: http://llvm.org/releases/download.html#2.6
> Oh huebsch! ... or sweet in English ...
> >
> > As for the splitting of the packages, it will be either difficult or
> > impossible to separate LLVM and Clang, is the problem.  Plus, I
> anticipate
> > Clang being _far_ smaller than the GCC frontend -- it shouldn't be much
> > trouble to include it in the LLVM package.
> I think you are wrong on both assumptions, just the clang_cc binary is
> 16 MB the combined libClang* come to 24MB so it is smaller than gcc I
> think but still significant. I do think, however, that there can be
> seperate packages, I have a pretty good idea which files are to put
> where.
>
> You are right that they will have to be build at the same time but we
> can split packages now from the same PKGBUILD file. Not that I would
> have done it yet but the pacman folks are working on it and AFAIK it's
> complete.
>
> The ugly part so far is, I haven't found a way to put clang_cc somewhere
> else than /usr/libexec which would be deprecated in Archlinux. If you
> move it around the static analyer barfs ...
>
> > The problem is that Clang must be built using the source from LLVM, and
> > seems to need to be compiled with LLVM.  That would suggest that to offer
> > Clang separately from LLVM, the two would have to be manually ripped
> apart
> > -- I can build LLVM, and I can build LLVM+Clang, but not just Clang.
> > That may be subject to change, of course, I may have missed something.
> >
> > So, the route I like would be to put LLVM+Clang in the llvm package, and
> > offer the GCC frontend as a separate optdep.
>
>    -T
>

[Tobias Kieslich]

Thanks,

I posted my llvm-clang-svn PKGBUILD in AUR, not all of the things made
it into the actual build. I like to have all scan-* wrappers included as
they are handy and depend on each other (scan-build -V invokes
scan-view automatically after a test build). They PKGBUILD is in the
comments of the package.

If you look at the llvm binaries provided you'll see the clang package
is bigger than the gcc stuff. However, the way they package it makes me
think it might be trick to separate clang from llvm but it sure is worth
a try.

        -T

On Mon, 26 Oct 2009, Ranguvar wrote:

> Very well, I'll make a prototype PKGBUILD that has sections for each install
> and then post it here, good luck :)
>
> I do think it odd though that Clang would be larger than GCC, I guess we'll
> have to see.
>

[Ranguvar-2]

Sorry, no idea what you're talking about in that first paragraph?
Where is the PKGBUILD?  And what do you mean by scan-* wrappers?

On Mon, Oct 26, 2009 at 7:16 PM, Tobias Kieslich <tobias@...>wrote:

> Thanks,
>
> I posted my llvm-clang-svn PKGBUILD in AUR, not all of the things made
> it into the actual build. I like to have all scan-* wrappers included as
> they are handy and depend on each other (scan-build -V invokes
> scan-view automatically after a test build). They PKGBUILD is in the
> comments of the package.
>
> If you look at the llvm binaries provided you'll see the clang package
> is bigger than the gcc stuff. However, the way they package it makes me
> think it might be trick to separate clang from llvm but it sure is worth
> a try.
>
>        -T
>
> On Mon, 26 Oct 2009, Ranguvar wrote:
>
> > Very well, I'll make a prototype PKGBUILD that has sections for each
> install
> > and then post it here, good luck :)
> >
> > I do think it odd though that Clang would be larger than GCC, I guess
> we'll
> > have to see.
> >
>

[Tobias Kieslich]

On Mon, 26 Oct 2009, Ranguvar wrote:

> Sorry, no idea what you're talking about in that first paragraph?
http://aur.archlinux.org/packages.php?ID=20222
latest  comment by neri (i attach my personal latest PKGBUILD to this
mail)
> Where is the PKGBUILD?  And what do you mean by scan-* wrappers?
scan-build and scan-view and the deps are not installed by default, the
PKGBUILD copies them manually. The are used to invoke the static
analyzer.

        -T

>
> On Mon, Oct 26, 2009 at 7:16 PM, Tobias Kieslich <tobias@...>wrote:
>
> > Thanks,
> >
> > I posted my llvm-clang-svn PKGBUILD in AUR, not all of the things made
> > it into the actual build. I like to have all scan-* wrappers included as
> > they are handy and depend on each other (scan-build -V invokes
> > scan-view automatically after a test build). They PKGBUILD is in the
> > comments of the package.
> >
> > If you look at the llvm binaries provided you'll see the clang package
> > is bigger than the gcc stuff. However, the way they package it makes me
> > think it might be trick to separate clang from llvm but it sure is worth
> > a try.
> >
> >        -T
> >
> > On Mon, 26 Oct 2009, Ranguvar wrote:
> >
> > > Very well, I'll make a prototype PKGBUILD that has sections for each
> > install
> > > and then post it here, good luck :)
> > >
> > > I do think it odd though that Clang would be larger than GCC, I guess
> > we'll
> > > have to see.
> > >
> >

# Contributor: Roberto Alsina <ralsina@...>
# Contributor: Tomas Lindquist Olsen <tomas@...>
# Contributor: Anders Bergh <anders@...>
# Contributor: Tobias Kieslich [tobias funnychar archlinux dot org]
pkgname=llvm-clang-svn
pkgver=85149
pkgrel=1
pkgdesc="Low Level Virtual Machine - Compiler infrastructure"
arch=('i686' 'x86_64')
url="http://llvm.org"
license=(custom:"University of Illinois/NCSA Open Source License")
depends=('libtool' 'libelf' 'gcc-libs')
makedepends=('gcc' 'subversion')
optdepends=('perl:    the scan-build tool for the clang static analyzer' \
            'python:  the helpers for the scan-view tool')
provides=('llvm')
conflicts=('llvm')
source=()
md5sums=()

# this is always the latest svn so debug info can be useful
# but llvm was always very stable for me
#options=('!strip')

_svntrunk=http://llvm.org/svn/llvm-project/llvm/trunk
_svnmod=llvm

build() {
  cd ${srcdir}

  if [ -d ${_svnmod}/.svn ]; then
    (cd ${_svnmod} && svn up -r ${pkgver})
  else
    svn co ${_svntrunk} --config-dir ./ -r ${pkgver} ${_svnmod}
  fi

  msg "SVN checkout done or server timeout"
  msg "Starting make..."

  rm -r ${srcdir}/${_svnmod}-build
  svn export ${_svnmod} ${_svnmod}-build

  # get clang in here
  cd ${srcdir}
  if [ -d clang/.svn ]; then
    (cd clang && svn up)
    cd ${srcdir}
  else
    svn co http://llvm.org/svn/llvm-project/cfe/trunk clang
  fi
  svn export clang ${_svnmod}-build/tools/clang

  cd ${_svnmod}-build

  # prepare the build
  # remove docs from the make targets
  # sed 's:runtime docs:runtime:' -i Makefile || return 1
  # remove examples projects and bindings from the make targets
  sed 's:examples projects bindings::' -i Makefile || return 1
  # remove libHello transformation
  sed 's: Hello::' -i lib/Transforms/Makefile || return 1

  # start the build - FIXME: make that libexec thing working for clang stuff
  ./configure --prefix=/usr \
    --sysconfdir=/etc \
    --libexecdir=/usr/lib/clang \
    --enable-optimized \
    --enable-assertions \
    --enable-pic \
    --enable-targets=host-only \
    --disable-bindings \
    --enable-shared \
    --enable-static \
    --disable-expensive-checks || return 1

  make -j2 || return 1
  make DESTDIR=${pkgdir} install || return 1

  install -Dm644 ${srcdir}/llvm-build/LICENSE.TXT \
    ${pkgdir}/usr/share/licenses/llvm/COPYING
  # install scan-build tool
  cd tools/clang/utils
  install -dm755 "${pkgdir}/usr/lib/clang/libexec"
  install -m755 scan-build    ccc-analyzer "${pkgdir}/usr/lib/clang/"
  install -m644 scanview.css  sorttable.js "${pkgdir}/usr/lib/clang/"
  # make scan-build available from path
  ln -s /usr/lib/clang/scan-build "${pkgdir}/usr/bin/scan-build"
  # make clang-cc available for scan-build (/usr/libexec is not searched but if we move the binary
  # clang-cc doesn't find the header files ... bummer)
  ln -s /usr/libexec/clang-cc "${pkgdir}/usr/lib/clang/libexec/clang-cc"
  cd ../tools/scan-view
  cp -pr Reporter.py Resources ScanView.py scan-view startfile.py "${pkgdir}/usr/lib/clang/"
  ln -s /usr/lib/clang/scan-view "${pkgdir}/usr/bin/scan-view"

  # no docs please -- these are justps and html formatted manpages
  rm -rf ${pkgdir}/usr/docs
}

[Ranguvar-2]

Just did a build with and without Clang.  The difference comes out to about
12MiB, actually -- 69MiB for LLVM, and 81MiB for LLVM+Clang.
12MiB is, incidentally, the size of the /usr/libexec/clang-cc file you
mentioned, so that's basically all the size difference.

Attached is a PKGBUILD which builds LLVM+Clang, comment out the mv line from
build() to build only LLVM.

On Mon, Oct 26, 2009 at 7:37 PM, Ranguvar <ranguvar@...> wrote:

> Sorry, no idea what you're talking about in that first paragraph?
> Where is the PKGBUILD?  And what do you mean by scan-* wrappers?
>
>
> On Mon, Oct 26, 2009 at 7:16 PM, Tobias Kieslich <tobias@...>wrote:
>
>> Thanks,
>>
>> I posted my llvm-clang-svn PKGBUILD in AUR, not all of the things made
>> it into the actual build. I like to have all scan-* wrappers included as
>> they are handy and depend on each other (scan-build -V invokes
>> scan-view automatically after a test build). They PKGBUILD is in the
>> comments of the package.
>>
>> If you look at the llvm binaries provided you'll see the clang package
>> is bigger than the gcc stuff. However, the way they package it makes me
>> think it might be trick to separate clang from llvm but it sure is worth
>> a try.
>>
>>        -T
>>
>> On Mon, 26 Oct 2009, Ranguvar wrote:
>>
>> > Very well, I'll make a prototype PKGBUILD that has sections for each
>> install
>> > and then post it here, good luck :)
>> >
>> > I do think it odd though that Clang would be larger than GCC, I guess
>> we'll
>> > have to see.
>> >
>>
>
>

[Ranguvar-2]

Alright, finished, wasn't as hard as I thought.  Here is a PKGBUILD I
believe works perfect for both an llvm package and a clang package, I'll
work on llvm-gcc and such soon :)

How should I proceed?
Do split packages even work on the AUR anyways?

On Mon, Oct 26, 2009 at 8:06 PM, Ranguvar <ranguvar@...> wrote:

> Just did a build with and without Clang.  The difference comes out to about
> 12MiB, actually -- 69MiB for LLVM, and 81MiB for LLVM+Clang.
> 12MiB is, incidentally, the size of the /usr/libexec/clang-cc file you
> mentioned, so that's basically all the size difference.
>
> Attached is a PKGBUILD which builds LLVM+Clang, comment out the mv line
> from build() to build only LLVM.
>
>
> On Mon, Oct 26, 2009 at 7:37 PM, Ranguvar <ranguvar@...> wrote:
>
>> Sorry, no idea what you're talking about in that first paragraph?
>> Where is the PKGBUILD?  And what do you mean by scan-* wrappers?
>>
>>
>> On Mon, Oct 26, 2009 at 7:16 PM, Tobias Kieslich <tobias@...>wrote:
>>
>>> Thanks,
>>>
>>> I posted my llvm-clang-svn PKGBUILD in AUR, not all of the things made
>>> it into the actual build. I like to have all scan-* wrappers included as
>>> they are handy and depend on each other (scan-build -V invokes
>>> scan-view automatically after a test build). They PKGBUILD is in the
>>> comments of the package.
>>>
>>> If you look at the llvm binaries provided you'll see the clang package
>>> is bigger than the gcc stuff. However, the way they package it makes me
>>> think it might be trick to separate clang from llvm but it sure is worth
>>> a try.
>>>
>>>        -T
>>>
>>> On Mon, 26 Oct 2009, Ranguvar wrote:
>>>
>>> > Very well, I'll make a prototype PKGBUILD that has sections for each
>>> install
>>> > and then post it here, good luck :)
>>> >
>>> > I do think it odd though that Clang would be larger than GCC, I guess
>>> we'll
>>> > have to see.
>>> >
>>>
>>
>>
>