debian/rules questions and my plans for dual-build.
Henrique de Moraes Holschuh
hmh at debian.org
Sun May 7 17:35:05 UTC 2006
On Sat, 06 May 2006, Sven Mueller wrote:
> I don't really get why you should be able to change the default here at
> build time. Or why it would make the patch harder to get into upstream
Because it emulates past behaviour, thus it can be deployed in a stable
series without much problems.
> if the --with-idle configure-option is removed. But if you want to keep
> a configure option to change the default, I would really suggest
> changing the option name to --with-idle-default, do clearly distinguish
> it from what the old option did.
That will not archieve the compatibility.
> > Instead, you want to keep WITH_IDLE, and make it select the *default* idle
> > backend. The manpages should be generated reflecting whatever default the
> > user coose using --with-idle, as well.
> Hmm, I have actually no idea how to achieve that, I probably really
> should learn how to use autoconf/automake some time.
I can do the auto-fu stuff, just tell me which C defines do you need to do
it cleanly. It needs not be anything related to C-defining WITH_IDLE.
> > The default selection should be the current upstream default.
> Which is "poll".
> > make idle_enabled(), idle_start(), idle_done(), etc macros (or keep
> > them as functions, but hint gcc that they probably should be inlined) that
> > does, e.g. the IDLE->enabled() test if IDLE is non-null. This minimizes the
> > changes to the rest of the code, and it is cleaner too (and faster if it is
> > just a macro that does ( if (config_idle != NULL) config_idle->enabled(); )
> > or something like that.
> Sorry, but how to you switch between different _inline_ functions at
> runtime? Those are functions which come directly from the different
You use the inline function to select the callback.
> idle-backends, as usual when you dynamically want to switch to the
> different implementations, this is done via function pointers.
You *still* have the function pointers, but you don't have them used
explicitly except inside the macro or function.
> moment (have been up since 30 hours or so now), so I would rather not
> mess it all up now that it is currently working.
There is no hurry for this, it is just that I have some experience with
Cyrus upstream, and we'd certainly like to get this into 2.3 and if at all
possible, 2.2 (and not just Debian-2.2).
> PS: Thanks Ondrej for the initial patch, I wouldn't have been able to
> implement it that fast.
Yes, it was quite a nice work! I doubt I'd have done it that fast, as well.
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
More information about the Pkg-Cyrus-imapd-Debian-devel