2011/2/22 Steven <redalert.comman...@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 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTim_NELaDptg3+Zxus=8vtjfniswmzej8fzes...@mail.gmail.com
