Re: autotools not suited to proprietary development?

[Andre Stechert]

Hi,


if you're installing onto a system that has a package manager).  From a

and something like InstallShield or NSIS.


When you're doing make install, try instead:

        make install DESTDIR=/tmp/staging


embedding references to your prefix in the appropriate places) and then

those to your customers.  Or zip them.

Cheers,
Andre

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

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 Windows perspective, it's the same as the difference between Visual Studio 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). Automake will build everything as if it's going to install to your -- prefix (including 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

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



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.


projects. The problem is the major assumption in autotools is that the

package is the same as the source tarball. I was unable, in the time

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'

build machine's prefix (via -rpath switch).


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,

of building the binaries, and putting them in a friendly distributable. In windows the deliverable is a zip file with .DLLs, .LIBs, and header 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 source code is being shipped to the end user, and thus the distributable allowed, to come up with a way to easily (ie clean, without many hacks) 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 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

smime.p7s
Description: S/MIME cryptographic signature