Re: autotools not suited to proprietary development?

[Ryan McDougall]

On Wed, 2006-10-04 at 20:11 -0700, Andre Stechert wrote:
> Hi,
> 
> I think you're confusing the idea of a build system for portable  
> software
> (something the autotools suite can help with) and an installer (or  
> package
> if you're installing onto a system that has a package manager).  From a
> Windows perspective, it's the same as the difference between Visual  
> Studio
> and something like InstallShield or NSIS.

I think is is quite true, years of free software having skewed my
experiences and spoiled me to easy source-based portability. :)

However the problem remains that Im at a bit of a loss how to ship a
shared .SO library easily. If I build on my machine (or a set of
supported build machines) then the build will link to my prefix (lets
say /usr/lib) and the end user has no choice where he wants to place his
library?

This is the kind of detail I would very much hope was solved by some
software somewhere...

Cheers,
> 
> One trick that may help is automake's "DESTDIR" variable, which  
> allows you
> to create a "degenerate" package (i.e., something that doesn't allow  
> you to
> do fancy system setup -- not unlike installing a Windows app from  
> a .zip file).
> When you're doing make install, try instead:
> 
>       make install DESTDIR=/tmp/staging
> 
> Automake will build everything as if it's going to install to your -- 
> prefix (including
> embedding references to your prefix in the appropriate places) and then
> at the last minute, it will take the files it was going to install  
> and "destdir" them
> at /tmp/staging.  Then you can simply tar/gz the files at /tmp/ 
> staging and ship
> those to your customers.  Or zip them.
> 
> Cheers,
> Andre
> 
> On Oct 4, 2006, at 7:41 PM, Ryan McDougall wrote:
> 
> > Hello,
> >
> >  First of all, Im only looking for serious answers, and I dont want to
> > start any flamewars, so Ill start out by saying that quite likely the
> > only problem here is my lack of knowledge of autotools, and the other
> > the issues involved. Please correct me at any point you disagree with.
> >
> >  After some cajoling of new company from myself -- a linux and free
> > software buff, and a lonely professor who wants to use one of our SDKs
> > on linux, it was finally decided to make a linux port of our
> > SmartCollision SDK.
> >  The C++ code is clean and portable, so "porting" really just consists
> > of building the binaries, and putting them in a friendly  
> > distributable.
> >
> >  In windows the deliverable is a zip file with .DLLs, .LIBs, and  
> > header
> > files that should work on any modern widows. The linux deliverable
> > should be the same, however, given the large amount of variability in
> > the linux world, I would like to have autoconf do as much work as
> > possible, which I think means getting the code to compile on my build
> > machine, and link on the users environment.
> >
> >  With my inexperience with doing proprietary development, I chose  
> > to use
> > autotools since I was the only tool I was familiar with from open  
> > source
> > projects. The problem is the major assumption in autotools is that the
> > source code is being shipped to the end user, and thus the  
> > distributable
> > package is the same as the source tarball. I was unable, in the time
> > allowed, to come up with a way to easily (ie clean, without many  
> > hacks)
> > give me the sort of solution I was looking for, which would look
> > something like:
> > './configure && make && make bindist' on the build machine
> > and
> > './configure && make && make install' on the end users machine
> >
> > As it is we just
> > './configure --prefix=/package/dir/ && make && make install'
> > then manually package the static libA.a libraries and headers  
> > there. We
> > couldnt do shared libraries since libtool wanted to link the .so to  
> > the
> > build machine's prefix (via -rpath switch).
> >
> > Has this problem been solved before with autotools? Or is this just  
> > not
> > a problem autotools wants to solve? If so, does anyone have  
> > alternative
> > recommendations?
> >
> > I ask because I have hope we can port our remaining products to linux,
> > and that I can learn how to do this sort of thing properly next time.
> > But if it gets too expensive for my boss, he wont be likely to approve
> > it.
> >
> > Cheers,
> >
> >
> >
> >
>