Re: packaging a new qt application with 2 components
2011/2/22 Steven <redalert.commander@gmail.com>:
> 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.
>
> [snip]
>
> 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.
You understand correctly.
But I'm not sure Debian would benefit much from a -dev package that
only exists to build a single other package. I'll leave it to the
Debian Developers on this list to comment on that, though.
> Upstream doesn't distribute anything but a Windows application and the
> code with custom build script from SVN.
But does checking out the SVN get you the entire application? Or does
that require two checkouts to get both kernel and gui branches? (Long
time since I last used 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)
I'm not intimately familiar with the Qt build system (I've only used
someone else's CMake script for Qt builds), but I believe qmake
handles some magic regarding the Qt meta-object compiler. If the
top-level Makefile is also generated from qmake, I'd try to get
debian/rules to execute qmake.
Again, someone else may have more experience with this.
> 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)
The more automated the build is, the easier the Debian packaging, as
long as some parameters such as installation dir can be set without
too much of a hassle. Do realise that if you make a debian/rules that
bypasses large parts of the upstream build system, you're going to
have to maintain it.
If you can get upstream to maintain a generic Unix build script that
is fit to be called from debian/rules, it saves work, even if it means
you get to maintain it for them.
> 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.
I'm getting very curious. What is this application?
Regards,
Lars
Reply to: