|
|
> That didn't stir up a lot of dust here, but it's still good news. I
> hope you're getting the help you need.
I'm currently working my way through the git log, trying to turn it into a
useful document.
I need to get Peter Bortas to tell me what I need to know to actually make
a build, but that isn't blocking my progress (yet).
> Unfortunately there's some risk that Roxen will take its usual
> liberties and go about its business in the pike source anyway: We have
> a customer project with a glue module against a SAML 2.0 client
> library (ZXID) and it's still fairly immature. I think we can keep the
> hacking inside that module though, so it can just be disabled in the
> official builds for now. I.e. we'll add a --with(out)-zxid config
> option and make --without-zxid the default.
Well, I really just sort of meant that folks should wrap up any pending
changes that they'd like to get into the build and try not to break things
between cutting a beta and the final release.
I'm less worried about ZXID, as it seems to be fairly well contained and
as you point out, can be marked as experimental. Given the incredibly
long lived branches we've been dealing with the past 6 or 7 years, it's
understandable that this is how things end up working.
If we get to the point where releases happen with greater regularity, it
would, of course, be nice if we all played by the same rules (whatever
they happen to be.) :)
> The concept of external module building still hasn't taken root in the
> Roxen build systems... :\
That's somewhat unfortunate, though I go back and forth on the merits of
it. Currently, I find the option of external modules quite useful and it
can really save time if you're making a lot of changes: the build time is
a lot quicker and you can more easily test out C modules by using pike
-M., which is something I do a lot.
The development version of Caudium uses the "external" module process for
all if its C language glue. Using that approach has made the build process
much simpler, as we don't have to maintain a separate set of build files.
I guess the only thing you really lose is history, if at some point the
module gets added to the core. After looking at the Whitefish history,
though, my impression is that the history can be joined, which eliminates
that issue.
Bill
|
Locked
