[sldev] Packaging the viewer for Linux distributions

Robin Cornelius robin.cornelius at gmail.com
Tue Oct 2 01:42:50 PDT 2007


Hi Callum,

On 10/2/07, Callum Lerwick <seg at haxxed.com> wrote:
> If you're talking about VWR-1853, you're mixing up two issues. There may
> be install manifest problems on x86_64, but the inability to find system
> fonts to use out of the box affects all architectures.

Yes i was mixing two issues :-) my bad. Yes the fonts is perhapses the
most annoying as you have to either patch the viewer and add your own
fonts, or symlink away.

>
> Note my RPM package just does a "release" build, with SConstruct patched
> to build as a "releasefordownload", basically to bypass the tarball
> building. It handles the install itself. So I'm not going to notice
> manifest problems. :) The "make" and "make install" stages should
"> probably be separated, like every other build system on the planet does.
> (And "install to an FHS compliant tree" and the current "build a binary
> tarball" separated as well)

Ok i see your point that the build system should work as *expected*
and do things as we are all use to seeing not do its own thing and a
"install" option that did the right thing would also be very nice.

I have not got as far as using my own makefile, I was relying on the
tarball building with all the correct contents then i was unpacking
this to a deploy directory with a .deb control file, moving a few
files around my hand and creating a deb that way. Have you posted your
makefile anywhere or could you send me a copy, could be pretty handy
for me building my debs.

>
> > I am sure there are others but VWR-2488 " Standalone build is almost,
> > but not quite there." might make a good umbrella for related issues as
> > it seems bang on topic.
>
> No, there's bigger issues than just building. :)
>

Point taken, I would just like to see the viewer build with out any
source code patching as a minimum first step, with whatever build
tool. ATM there are a few issues, the font one and "expat/expat.h" is
not where it is expected to be (its just "expat.h"). Thats it for me
but i am sure there are others

So what would anyone say the next step would be, move to a different
build system? Are you saying a full automake/autoconf setup to replace
scons so that things build correctly on different arch's and even
cross arch? and can install files into correct (FSH) locations etc.
This would certainly make packaging easier.

Are there any other blocking issues here as well?

Robin


More information about the SLDev mailing list