Re: [Pan-users] I want to try to build Pan from the git

[Duncan]

Bob posted on Thu, 02 May 2013 19:58:24 +0000 as excerpted:

> On Thu, 02 May 2013 19:54:39 +0000, Bob wrote:
> 
>> what would I need to download to do so?
>> Am running Mint 13 Maya (LTS) AMD-64.
>> 
>> Already posted similar message in the developer group,
>> 
>> Bob
> 
> OOP's also have Mint LMDE 201303 AMD-64 newly installed and running.

I'm not the best authority on this, as I run gentoo, which being end-user 
build-from-source by default, doesn't do the runtime/buildtime package 
splits that most binary distros do.  However, since nobody else seems to 
be responding... and years ago I did run a binary-based distro (Mandrake) 
and build from sources for some things, so I do know a bit about it...

The easiest way to build from live-git on a binary-based distro is to 
break it down into steps.  Note that the below is a bit of a worst-case, 
and that in most cases, other than the runtime/devel split I mention 
below, which a good package management system should pretty much take 
care of for you with step #1, it ends up sounding much worse than it 
actually ends up being when you actually do it.

Step one, get the existing distro package to build from source using its 
source-package (srpm or whatever, I don't know what debian-based-distros 
call the source package).  That will pull in most of the dependencies you 
need, including the -dev/-devel packages for the necessary libraries.

It's worth noting specifically once again, since it confuses nearly 
everybody on a binary-based distro the first time or two they build 
something from source, that binary-based distros break most of their 
libraries into two packages, the runtime package that is commonly 
depended upon by other binary packages using that library, and the build-
time or -dev(el) package that only those building anything that depends 
on that library from source need.  The runtime package contains the 
actual library binaries, while the build-time package contains the 
headers (*.h files), pkgconfig files (*.pc), etc, that aren't needed to 
actually run anything using that library, but ARE needed to build against 
it.

So if you see an error that libsomething.so isn't installed when you know 
it is, what's normally because the libsomething-devel package isn't 
installed, so while the binary/runtime bits of the library might be 
installed, it can't be used to build anything because the -devel package 
is missing.

By first building the existing version from sources using the distro's 
normal source-package, its package-manager should pull in most of these 
-dev packages automatically, and if it misses any, you should get an 
error that's easier to match up to a missing -dev package or whatever, 
than you would if you went straight to building live-git.

Of course, that also serves as a "gentle" intro to building from source, 
while the distro package manager is still managing most of the deps, etc, 
thus taking some of the mystery out of it while getting you used to the 
general procedure, what a normal build looks like, etc.

Step two, once you can successfully build and run the distro's existing 
version from its existing sources, advance to the latest version tarball 
from upstream, pan 0.139 in our case.

Sometimes, you'll need a later version of some library than what shipped 
with your distro, since you're now building upstream's latest shipped 
version.  Other times, the distro did some distro-specific patching 
making its version easier to build on that distro, or something, and 
you'll need to figure out how to make the unpatched sources build or to 
patch them yourself.  But by this point you should recognize what's going 
on a bit more, making it easier to figure out the problem and the version 
of the library you need to update to, if that's the problem, or be able 
to tell because it's looking in the wrong place for something compared to 
what the distro version did, that the distro version was either 
configured special to look where it looked, or patched to do so, thus 
being familiar with what your native distro version build looks like is 
already half the answer to any problems you encounter at this stage.

It's also worth noting that package source tarballs typically include 
INSTALL and/or README files that tell you something about what you need 
to build the package, and how.  Sometimes there's similar information on 
the package's homepage.  Pan is no exception.

Once you get the latest release-version from upstream successfully 
building and running, THEN go for step 3, actually trying the git-live 
version.

This step can actually be the hardest, because there's less documentation 
on it, and there's often some additional dependencies that aren't needed 
for building from a release tarball, because part of the release process 
is doing some pre-config, etc, that individual users have to do when 
they're building from the raw un-release-prepared sources.  (The same 
files are often there, just outdated, as the sources have changed since 
the last release updated the pre-config files to match the sources.)

And honestly, I remember not being able to overcome this step back on 
mandrake for some time -- I could build from a release tarball, but not 
from the live sources, and I didn't know what I was missing.  I don't 
remember for sure whether I /ever/ actually overcame that on mandrake, or 
whether it was only after switching to gentoo, that I was able to do it, 
everything seeming to "just work", because gentoo actually defaults to 
building from sources so makes vastly different assumptions about the 
tools and configuration that should be default on the distro.

I still don't have the greatest personal understanding of this step, but 
I've been able to guide a number of folks thru it, by "cheating", as it 
were, just looking at the gentoo live-ebuild (or one for another similar 
package if there isn't one for that package, tho for pan there is, so 
it's easy enough) to see what it does, one command at a time, and having 
the person I'm guiding thru the process do the same thing, only manually.

When you get to that point, I'll do that.  Meanwhile, it's enough for now 
to describe it in higher level terms.  Pan, like many free/libre and open 
source packages, is autotools based.

When one builds from a release tarball, normally all one does is unpack 
the tarball, cd into it, run ./configure (which is a script that detects 
what's available on the platform and sets up the build appropriately), 
then make (which actually builds the binaries from sources), then make 
install (which installs the binaries made in the last step).

But, where did this configure script come from?  It's auto-generated by 
the various components of the autotools package, automake, autoconf, etc, 
in several steps, from much shorter "recipe" files.  Running these to 
update the configure script against the latest sources is a routine part 
of preparing for a release, and is thus normally already done in the 
release-version tarballs a project ships.  But once you graduate to the 
level of building from live-sources, you're typically building from 
sources that have changed since the last time the configure script was 
built, so it may be outdated and no longer function as expected, unless 
you do the release-prep steps yourself.

The problem is that except for developers themselves, this whole process 
isn't so well documented, and the documentation for developers tends to 
be *MUCH* more complicated than it should be for a non-dev normal end-
user simply trying to build the current unreleased sources.  Among other 
things, there are several versions of autoconf, automake, libtool, etc, 
and if a project's using a version different than what a distro ships, 
there can be issues getting it to work properly.  Not to harp on it /too/ 
much, but this is one of the areas where a default-from-source distro 
tends to be far easier, because it normally assumes its users are going 
to be /doing/ such things.  For example, on gentoo, it's routine to have 
several versions of automake and autoconf installed at the same time, 
parallel to each other, with a wrapper that normally sorts out which one 
should be used, and a method of specifying one version directly, if for 
some reason the wrapper is making the wrong choice.  On a binary-based 
distro, by contrast, the assumption is that most users will only run 
packages pre-built by the distro, and if there's autoconf and automake 
installed at all by default, there may not be provision to install 
different versions in parallel, making it far more of a hassle to build a 
package that doesn't work with a distro's default version.

Of course, whatever VCS (version control system, most often git these 
days as it is with pan, but it used to be svn most often, and rcs before 
that, and there's other VCSs as well) an upstream uses, must be installed 
as well, once you're building from live sources.  That's unnecessary when 
building from a pre-packaged tarball.  However, given that you already 
specified building pan from git, it's likely you already expected this 
requirement.

So anyway, once you get step #2, building from the latest pan tarball, 
working, and have git installed and are otherwise in general ready to go, 
post again to that effect, and if nobody else does, I'll try to guide you 
thru the additional pre-configure steps.  Again, it probably looks a lot 
worse as I've described it above than it actually is in practice, but I 
know I passed the other hurdles easier than I did this one, which took me 
quite awhile, and I may have only done it once I switched to gentoo.  But 
as I've said, I've helped others thru it, so it's possible.  And if 
you're lucky, your distro might make it easy enough that you find you 
don't need the extra help I and others did to get over that hurdle, after 
all. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman