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.asc
Description: This is a digitally signed message part