Raul Miller <[EMAIL PROTECTED]> writes: > > And I do want to provide the Qt-CORBA interface. (I want to build > > some services that work from both Gnome and KDE - a step towards > > merging them, if you will, which is not wrong-headed) > > I'm confused. > > You've specified that the qt configuration bit only affects a few files. > > If this is really true, it seems like you could build mico without qt > configured, take a snapshot of file time stamps, reconfigure it so that > it supports qt, re-apply the time stamps, then conclude the build.
Actually, in mico 2.0.8, I think the inclusion of the --with-qt flag only triggers the inclusion of an additional shared library, so that's mostly a non-issue. The problem is to design a debian/rules that does different things depending on whether the user wants to build the non-free/contrib packages, or not. ie. If somebody doesn't have Qt installed, they don't want the package build scripts to be trying to build that package. I've got a really simple little scheme that uses a custom shell script "debconfigure" file (in the debian directory), which takes a rules.in file and generates a rules file that is appropriate. I'll ship the package with a rules files that doesn't generate the non-free/contrib packages. If somebody wants them, they can go to the debian directory of the source tree, run "./debconfigure --contrib", and presto, running dpkg-buildpackage or "fakeroot debian/rules binary" will build all the packages they want. As it currently stands, I'm not going to put together mico 2.0.8 right away. Gnome needs mico 2.0.5 (actually a hacked up version of it) - so I've done that instead for now. Cheers, - Jim
pgpYf0QLZhAOh.pgp
Description: PGP signature
