Compiling hugin on Gentoo
Thomas Pani
I've written some Gentoo ebuilds to build hugin, libpano13, autopano-
sift-c and enblend from SVN/CVS.
There's also a little howto at [1]. It'd be nice if someone could add
a link on Hugin's download page (like the ones for Ubuntu/Fedora).
Also, should anyone here be running Gentoo (and wants to upgrade from
0.7_beta4), please try them ;-)
Regards,
thomas
[1] http://wiki.panotools.org/Hugin_Compiling_Gentoo
Yuval Levy
> I've written some Gentoo ebuilds to build hugin, libpano13, autopano-
> sift-c and enblend from SVN/CVS.
DANKE, Thomas!
> There's also a little howto at [1]. It'd be nice if someone could add
> a link on Hugin's download page (like the ones for Ubuntu/Fedora).
Done.
I also linked it from the development process page on the wiki,
<http://wiki.panotools.org/Development_of_Open_Source_tools#Supported_Platforms>
Was it a difficult job to write the ebuilds? is it possible to document
the process of writing the ebuilds - specifically what it takes for
those ebuilds - on an additional wiki page, so that they can be
maintained in the future? and would you like to be the maintainer for now?
thanks a lot
Yuv
Thomas Pani
> DANKE, Thomas!
Gern geschehen ;)
> Was it a difficult job to write the ebuilds? is it possible to document
> the process of writing the ebuilds - specifically what it takes for
> those ebuilds - on an additional wiki page, so that they can be
> maintained in the future? and would you like to be the maintainer for now?
I don't know if/how familiar you are with Gentoo, so I'll go into detail
here.
The nice thing about Gentoo is, that usually everything is built from
source. So, ebuilds are (in a nutshell) bash-scripts which hold some
metadata (dependencies and so on), and some functions that will take
care of compiling/installing (i.e. calling ./configure, make, make
install, ...). There's comprehensive documentation on ebuild writing at
[1] and [2].
Usually ebuilds are maintained by Gentoo developers. Actually, Gentoo
has ebuilds for hugin (0.7_beta4) and enblend (3.0) in the main
package-tree, but I thought it would be nice to have the new versions
from svn/cvs (plus autopano-sift-c and libpano13). So, what I did was
taking the original ebuilds (if they existed), updated dependencies and
changed the build process to cmake where necessary.
Now, here comes the important thing: As Gentoo builds from source, it
also supports so-called "live ebuilds", which will download the source
code from CVS or SVN and compile.
So, installing from my ebuilds will always give you the binaries
compiled from current HEAD revision in the trunk. (Though you could
write ebuilds that compile a specific revision.) Thus, it's not really
necessary to maintain these ebuilds like you would with RPM's or *.deb's
(unless something like dependencies or the build process itself change).
However, live ebuilds must not be included in Gentoo's main package-tree
(because cvs/svn sources are often unstable). So, I'd suggest I will
take care of updating the ebuilds (should it be necessary) until there
is an official release. Then it's up to Gentoo's developers to get
updated ebuilds into the main tree.
Thanks,
thomas
[1] http://devmanual.gentoo.org/index.html
[2] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1
Yuval Levy
sorry I am answering this one a bit late.
Thomas Pani wrote:
> I don't know if/how familiar you are with Gentoo, so I'll go into detail
> here.
thanks for the explanations.
> Usually ebuilds are maintained by Gentoo developers.
I think that one of them expressed interest to review your work in the
comments on
<http://panospace.wordpress.com/2008/06/27/hugin-on-gentoo-linux/>
> Now, here comes the important thing: As Gentoo builds from source, it
> also supports so-called "live ebuilds", which will download the source
> code from CVS or SVN and compile.
>
> So, installing from my ebuilds will always give you the binaries
> compiled from current HEAD revision in the trunk.
and can you get an ebuild to get a specific SVN/CVS revision rather than
HEAD? there is no guarantee that HEAD always builds, but it is possible
to give a reasonably recent revision that does.
> However, live ebuilds must not be included in Gentoo's main package-tree
> (because cvs/svn sources are often unstable). So, I'd suggest I will
> take care of updating the ebuilds (should it be necessary) until there
> is an official release. Then it's up to Gentoo's developers to get
> updated ebuilds into the main tree.
that would be cool for Gentoo users, thanks. I'd kindly ask you that
before you lose interest in updating the ebuilds to document what is
necessary to do to update them, so that the next person in line won't
have to start from scratch.
again, thanks a lot for making hugin available to Gentoo users.
Yuv
Radtoo
> necessary to do to update them, so that the next person in line won't
> have to start from scratch.
ebuilds are self-explanatory to anyone who's familiar with the matter.
Also, as you have noticed, the ebuilds linked on the wiki here are
building directly off SVN - that means unless you change the build
system or you become incompatible with newer versions of the
dependencies, there's no changes required to keep them working. And
even then the changes would be most likely trivial.
> and can you get an ebuild to get a specific SVN/CVS revision rather than
> HEAD? there is no guarantee that HEAD always builds, but it is possible
> to give a reasonably recent revision that does.
Gentoo has got ebuilds for the release versions of hugin & co that are
based of compressed tarballs. There's thus no point having an ebuild
that builds off tagged svn versions.
If users really needed this specific functionality they could,
however, select arbitrary versions / branches / tags (any svn option,
really) by setting a command line variable prior to installation.
Bottom line, it shouldn't be a problem. Though of course Gentoo/
Sabayon would make good testing platform, if you need some for
Linux. :)
Wolfgang Goetz
> Hi all,
Hi Thomas!
> I've written some Gentoo ebuilds to build hugin, libpano13, autopano-
> sift-c and enblend from SVN/CVS.
OK for me on amd64
i had to tweak the following:
** enblend-9999.ebuild:
MAKEOPTS="-j1" emake || die "Make failed"
** adding *really* enough swap (506036 + 1199992)
** deleting old ~/.hugin
great work!
good night...
Wolfgang
--
Wolfgang Goetz
Yuval Levy
> Hey, sorry to pop up at random
no need to be sorry, you are contributing to the discussion :-)
> ebuilds are self-explanatory to anyone who's familiar with the matter.
that's the whole point of documentation: not everybody is familiar with
the matter. I don't ask for a full explanation of what ebuilds are, but
for a quick "how-to" that a motivated person that is *not familiar* with
the matter can follow to get quickly up to speed without the need to
learn everything about ebuilds.
> Also, as you have noticed, the ebuilds linked on the wiki here are
> building directly off SVN - that means unless you change the build
> system or you become incompatible with newer versions of the
> dependencies, there's no changes required to keep them working. And
> even then the changes would be most likely trivial.
trivial to you (I assume you are an expert), but not to me (my whole
experience with Gentoo was a quick install and a little bit of play 3-4
years ago).
> SVN also is a bit too adventurous for some Gentoo users, official
> Gentoo has got ebuilds for the release versions of hugin & co that are
> based of compressed tarballs. There's thus no point having an ebuild
> that builds off tagged svn versions.
each compressed tarball that is an official release has an equivalent in
SVN. SVN is only adventurous if the revision chosen is HEAD or random.
There is at least one compelling reason to have an ebuild that builds
off specific SVN revisions.
Making an official release / tarball is a lot of work and we are
resource strapped. So the old 0.7beta4 (last tarball IIRC) is 14 months
old and *very* outdated. So much so that it motivated me to build and
distribute newer Windows binaries, and it obviously also motivated
Thomas to write an ebuild from SVN.
Those bleeding edge builds are in the interest of the project because
testing feedback^/ bugs reports related to them are relevant, as opposed
to bug reports based on 0.7beta4 which are no longer relevant. We don't
have the resources to support two versions, so users on 0.7beta4 are on
their own, and the recommendation is to use a recent SVN build. Tom,
Guido and I provide Windows builds, roughly every week. Ippei and Harry
provide OSX builds, roughly every two weeks. For the most mainstream
Linux platforms there are instructions linked from
<http://wiki.panotools.org/Development_of_Open_Source_tools#Build_your_Own_Test_Builds>
(oups, I see I need to update the revision numbers there).
So building from SVN is the right thing to do now - the tarballs are stale.
But SVN is alive and we can't guarantee that HEAD will always build.
There is however a very good chance that one of the last 10-15 revisions
builds well and is good enough to use too. Hence the need to bind to a
specific SVN number, to provide a recent, usable build so that testers
can give us further feedback.
> If users really needed this specific functionality they could,
> however, select arbitrary versions / branches / tags (any svn option,
> really) by setting a command line variable prior to installation.
eh... which variable, where, how? this is exactly the kind of detail I'd
like to see documented. But of course it's the choice of the platform's
users.
> Bottom line, it shouldn't be a problem. Though of course Gentoo/
> Sabayon would make good testing platform, if you need some for
> Linux. :)
yes we need, always :-)
Yuv
Thomas Pani
sorry for responding so late, I've been on vacation till yesterday.
> > Usually ebuilds are maintained by Gentoo developers.
>
> I think that one of them expressed interest to review your work in the
> comments on
> <http://panospace.wordpress.com/2008/06/27/hugin-on-gentoo-linux/>
>
version of hugin into the offical package tree.
> and can you get an ebuild to get a specific SVN/CVS revision rather than
> HEAD? there is no guarantee that HEAD always builds, but it is possible
> to give a reasonably recent revision that does.
>
variable in the ebuild).
> I'd kindly ask you that
> before you lose interest in updating the ebuilds to document what is
> necessary to do to update them, so that the next person in line won't
> have to start from scratch.
>
Thomas Pani
> i had to tweak the following:
> ** enblend-9999.ebuild:
> MAKEOPTS="-j1" emake || die "Make failed"
>
fixed.
What exactly fails if you build with > -j1 ? I'd prefer to see this
fixed than to put this restriction in the ebuild (though it wouldn't
bee a big problem on x86/amd64/ppc).
Thanks,
thomas
Thomas Pani
> testing feedback^/ bugs reports related to them are relevant, as opposed
> to bug reports based on 0.7beta4 which are no longer relevant. We don't
> have the resources to support two versions, so users on 0.7beta4 are on
> their own, and the recommendation is to use a recent SVN build. Tom,
> Guido and I provide Windows builds, roughly every week. Ippei and Harry
> provide OSX builds, roughly every two weeks.
> There is however a very good chance that one of the last 10-15 revisions
> builds well and is good enough to use too. Hence the need to bind to a
> specific SVN number, to provide a recent, usable build so that testers
> can give us further feedback.
easy to write.
I think a good idea would be if I provided updated ebuilds along with
your Windows
binaries (i.e. the same revision). A new ebuild every week wouldn't be
too much work
(it's just updating the ebuild version in the filename and the
revision in-file).
Do you have any process to determine which is a usable revision?
> eh... which variable, where, how? this is exactly the kind of detail I'd
> like to see documented. But of course it's the choice of the platform's
> users.
to provide revision-bound ebuilds anyway. However, handling is a bit
different
to HEAD-only-ebuilds (i.e. you don't have to update anything in a HEAD-
bound-ebuild,
but you have to change version/revision-numbers in rev-based-ebuilds).
thomas
Yuval Levy
> SVN-based ebuilds bound to a particular revision are easy to write.
excellent! right now we are in exactly that situation with
enblend-enfuse: if I am not mistaken 18-July-2008 is the last one to build.
> I think a good idea would be if I provided updated ebuilds along with
> your Windows binaries (i.e. the same revision). A new ebuild every
> week wouldn't be too much work (it's just updating the ebuild version
> in the filename and the revision in-file).
I don't know ebuilds in detail, but if they are like FreeBSD ports can't
you have a configurable parameter? your updated ebuilds would suggest a
default (e.g. right now SVN 3245 for hugin and CVS -d 18-07-2008 for
enblend-enfuse) that the user can override at their responsibility?
Mirroring what the rest of the builders do is a good idea. Mirroring
what *I* do is not. I don't want to be a SPOF
<http://en.wikipedia.org/wiki/Reliability_engineering>
My last published installer is SVN3082, two months ago. I've built a few
newer versions since then (it's an incremental process that is
relatively easy once set up) but there is a significant difference
between building for self-test and building for publishing.
I've had two attempts at going through for publishing in the past two
months but they both did not result in a new installer. I've just
finished the process for publishing with an installer that will be
bundled with the Nodal Ninja (SVN3242 which for all practical use is the
same as SVN3245 aka RC1). For distribution reasons it does not feature
any of the SIFT-based functionalities.
> Do you have any process to determine which is a usable revision?
sort of.
first: it has to build. If it does not, I try to isolate which change
broke the build and ping the developers.
second: I use it. I have a few test cases, though currently they are
scattered on my HDDs. I intended to make a more formal process, but for
now I usually set up a project or two from scratch and see that
everything works as intended. If there are no significant improvements,
I don't release - the installer is stable enough to be useful.
third: I go through the process of cleaning up for a release. This means
going through the different readme files and make sure they are more or
less updated. I've been sloppy on that one with my last installer. the
minimum here is to make the files readable in Windows (CR+LF!) and make
them clickable in Windows explorer (.txt extension). I also clean up for
consistency, i.e. license texts naming conventions, etc.
fourth: I compile the installer (the files are all in SVN, but so far I
am not aware of any other person who has used them, which is bad because
it makes me a SPOF and in a few weeks my first son will be born and I
will have much less time for this).
fifth: I test the installer. Here too, currently it is an ad hoc
process. I intend to set up VMware instances of Windows to test it with
different OS versions and so, but for now it is just the one single
workstation that I have, Windows XP. Previously I was testing also
install on Windows XP x64, but I have wiped that partition from my HDD
since. Currently I run WinXP inside a VMware in Linux about 50% of the
time, and stand alone the rest of the time. I try to test stand alone
before releasing.
sixth: I consider whether to release. There are always risks inherent in
a new release, so the first criteria I consider is whether the release
will improve the user's life or the quality of the feedback that we get
in the bug tracker. As long as the bugs reported in the tracker are
current enough and the pipeline to the developers is full, I see no need
to make a new release. As long as the new build does not improve the
user's life, I don't see a reason to make a new release. this is quite
different from the test builds that are provided by Tom and Guido quite
regularly.
I hope this helps give you insight into my process, and maybe developing
a process of your own. Linux users are different from Windows users, and
you want your process adapted to their needs.
Yuv
Thomas Pani
> I don't know ebuilds in detail, but if they are like FreeBSD ports can't
> you have a configurable parameter? your updated ebuilds would suggest a
> default (e.g. right now SVN 3245 for hugin and CVS -d 18-07-2008 for
> enblend-enfuse) that the user can override at their responsibility?
>
isn't possible. What is possible (and what I intend to do) is the following:
ebuilds are named in the form name-version.ebuild
Now, with RCS-based sources it's obvious to use the revision number as
version. Inside the ebuild this version can be accessed via the $PV
variable. So, I can supply the SVN URI like this:
ESVN_REPO_URI="https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk@${PV}"
which means if somebody really wants to build a different revision than
what I supply, he can just rename the ebuild.
I'll put up an svn- or git-repo somewhere to host ebuilds with fixed
revisions I consider "stable". There's a pretty nice tool (called
layman) that takes care of syncing overlays (third-party package repos).
>> Do you have any process to determine which is a usable revision?
> sort of.
> [snip]
>
> I hope this helps give you insight into my process, and maybe developing
> a process of your own. Linux users are different from Windows users, and
> you want your process adapted to their needs.
>
Thanks a lot for explaining your process. I'll get into it and see how I
can adapt it for Linux user compatibility ;).
thomas