On Tue, 2011-02-22 at 00:23 +0100, Lars Buitinck wrote:
> 2011/2/22 Steven <redalert.commander@gmail.com>:
> > Yes, looking in the directory, I see a single .a file, starting with
> > 'lib' (also the largest file in there). I guess this means it would be
> > easiest to create 2 separate packages, while changing the *.pro file for
> > the gui?
>
> If you want to keep them separate, that would be the easiest. If the
> 'kernel' is named libfoo.a, make a package called foo-dev or
> libfoo-dev containing it and the necessary headers, then make sure the
> gui package Build-Depends: on it. (No need to have it around at
> runtime.)
Hmm.. Sounds good, I'll have a look at it. So the libfoo-dev (or
foo-dev) would contain the 'kernel' and the dependency only exists when
building if I understand correctly.
>
> > Thus only linking to the 'kernel' instead of making a single binary.
>
> Linking to a static library (.a) in fact will produce a single binary:
> elements of the library are copied at link time.
>
> (You could build a shared library out of the 'kernel' library, but
> that's not for the faint-of-heart.)
That is definitely not necessary at this time, the 'kernel' would only
be used in combination with the Qt gui, although I guess I could change
it later if other applications start using it.
>
> > Changing the build procedures shouldn't be a problem for upstream.
>
> I'm a bit confused here. Is upstream distributing everything in a
> single package, or in two packages?
>
> In the former case, you'd want to build both the library (assuming
> it's generally useful) and the GUI from the single upstream package.
> In any case, there's no need for upstream to modify anything; just
> skip the top-level makefile in the debian/rules script using the
> --sourcedir argument to debhelper and point to the library in /usr/lib
> instead of in the source directory.
>
Upstream doesn't distribute anything but a Windows application and the
code with custom build script from SVN.
I'm not sure about how this would work in practice, but I'll try to
figure it out. While I see why one would use only build-depends, I'm not
sure how to accomplish the compile, as the make file is generated from
qmake. Or should I direct the Debian/rules file to run qmake instead
of/after make? (Always willing to learn)
Actually I think I should ignore the custom build script entirely for
building the Debian packages, and just edit that script a bit for
general *nix installs. It only executes qmake and make a couple of times
with some parameters to enable debugging, the rest of the script checks
the directories where to find the sources and uses 'echo' to output some
information about the progress and/or failures ((q)make commands are
redirected to a file, so you don't 'see' the compile process)
Here is some background history on the application which might help you
understand my position in this.
The application was originally developed for Windows, but after some
time a community member did the necessary work to make the
'kernel' (almost) compile on Linux and Mac OSX systems. He then started
writing a basic Qt gui to replace the native Windows gui. Both the
Windows and Linux branches exist in SVN, and so does the Qt gui.
For a while nothing really happened, but there was still interest in a
Linux version, I picked things up and my first patches made the whole
thing compile without manually editing source files (build script did
exist)
I'm currently fixing translations (still some hard coded German strings
in there) and doing some bugfixes.
So if you look at it like this, I do have some liberty to play with the
build script a bit, as long as I don't make it Debian specific so it can
still compile on other systems without issue.
Thank you very much for your help, I hope I'm not too much of an
inconvenience with all this text.
Kind regards,
Steven

Attachment:
signature.ascDescription: This is a digitally signed message part