[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: autotools not suited to proprietary development?

From: Andre Stechert
Subject: Re: autotools not suited to proprietary development?
Date: Wed, 4 Oct 2006 20:11:16 -0700


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.

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.


On Oct 4, 2006, at 7:41 PM, Ryan McDougall wrote:


 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
'./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

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


Attachment: smime.p7s
Description: S/MIME cryptographic signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]