| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 3 | |
I have a Qt app that internally uses several pre-built command line utilities and I'm wondering what the recommended practice is for distribution in a cross-platform way. Including them within the .app bundle on OS X seems most natural, and probably just dropping them in the program directory on Windows would be OK. What about Linux? Is there anything in the qmake build process that supports anything like this? Any thoughts, documents or info to peruse would be greatly appreciated - thanks! Liam -- [ signature omitted ]
Liam Staskawicz wrote:
>I have a Qt app that internally uses several pre-built command line
>utilities and I'm wondering what the recommended practice is for
>distribution in a cross-platform way. Including them within the .app
>bundle on OS X seems most natural, and probably just dropping them in
>the program directory on Windows would be OK. What about Linux? Is
>there anything in the qmake build process that supports anything like
>this?
On Linux, I'd install in your libexec or lib dir. libexec is what
autotools recommend, but no Linux distribution seems to have taken that
up -- lib is preferred.
${prefix}/libexec/appname/
${prefix}/lib/appname/
In general, prefix=/usr when building as part of a distribution, but
defaults to prefix=/usr/local in all packages when building from source.
It can also be /opt/appname.
--
[ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
On Mon, 2008-05-12 at 17:47 -0700, Liam Staskawicz wrote:
> I have a Qt app that internally uses several pre-built command line
> utilities and I'm wondering what the recommended practice is for
> distribution in a cross-platform way. Including them within the .app
> bundle on OS X seems most natural, and probably just dropping them in
> the program directory on Windows would be OK. What about Linux? Is
> there anything in the qmake build process that supports anything like
> this?
>
> Any thoughts, documents or info to peruse would be greatly appreciated
> - thanks!
This is a question that I recently faced myself. I'll put in my two
cents worth. This is what I have gleaned from studying other software
packages. YMMV.
On the MacOS I put the executable in the bundle's Resource directory.
It seemed to be where others placed such utilities.
On Windows it should go in your application directory. Depending upon
the complexity of your software, you may want to group multiple external
applications into a separate folder under the application folder.
Linux is the tricky part because it all depends on your customers, your
distribution method and the function of your program.
First, let's assume that you are distributing the software as a native
package, be it a redhat rpm or a debian pkg. The key element is that
the system has a way of knowing which files belong to your software.
Then the file can go into the /usr hierarchy. If you're not using the
native package manager, then it's just rude to put things
in /usr/{bin,lib,share} etc..
If your command line utility should never be called by anyone but your
application, it should go into a /usr/libexec/appname folder.
If your command line utility _could_ be used externally to your main Qt
app, then it should go into /usr/bin. A good example is doxygen and
doxywizard. The command line doxygen is expected to be used from a
shell.
If you're using an archive (.tar.gz, .zip, or similar) of your prebuilt
executable with an installation script of your own construction, then a
common practice seems to be using either /usr/local/AppName/bin
or /opt/AppName/bin. Optionally, if you distribute multiple software
packages, you might want to consider /usr/local/CompanyName/AppName/bin
or /opt/CompanyName/AppName/bin. In this case everything should go
under the AppName directory. Your executables, libraries, help files,
etc. should all be located there. This is especially true if you are
distributing Qt's shared library files with the software rather than
relying on the locally installed version of Qt.
Good examples of this sort of packaging are Wolfram's Mathematica, Adobe
Reader and Google Desktop, Earth, etc.
As a user, I prefer the /opt directory installation to the /usr/local
directory. This is _purely_ a matter of opinion. I just like to keep
the /usr/local directory exclusively for software that I build from
source without a package manager. I would rather not have prebuilt
binaries located in there.
Finally, it's important to keep in mind whether or not your software
customer has root access to the machine. It can be an enormous pain for
a user at a large company or a university if they have to track down
(and possibly wait days for) a system administrator to install the
package for them. In this case, having a relocatable package which can
be put in a user's home directory is a nice option. Just because the
computer is sitting on their desk doesn't mean that they have root
access.
Relocatable packages are good because they can be used by a single
person in $HOME or installed in /opt or /usr/local for use by everyone.
Good examples of relocatable packages are the Adobe and Google software
packages mentioned above. Look at them, study them, emulate them.
That's my advice.
I've struggled through days of long phone calls with frustrated users
and their system administrators while they try to rebuild everything
from scratch on their system. I've also tried building multiple copies
of packages for a wide variety of distributions. The relocatable
package is now my preferred distribution method on Linux. I'm slowly
switching all of my applications to that method. Simple to install,
simple to blow away.
Like I said, YMMV.
Fred Bacon
Senior Scientist
Aerodyne Research, Inc.
Billerica, MA 01821
--
[ signature omitted ]