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, > > > > > > > > >