Eric Wilhelm wrote:
>I see you're using the subclass() method and do($file). This might be
>more readable if you just put it all in a subclass in inc/MyBuilder.pm
>and "use lib 'inc'".
Seems to me that there's not enough subclass code to get any benefit
from putting it in a separate file. The feature tests themselves I
do want to have in a separate file, so that they can be edited and
take part in dependency calculations just like any other source file,
but they don't particularly belong logically in the subclass or in the
module namespace at all.
>Also, I think you might want to override ACTION_code(). Is there a
>reason to have it in compile_c() ?
I prefer to trigger the probing in the place where its results are used.
That's actually in compile_c. I don't want to rule out that compilation
being triggered by some other action.
> That is, it looks like the "only
>once" logic attached to no_feature_defs wouldn't be needed in
>ACTION_code().
I'd want the caching logic anyway. This data can be cached between
invocations of the Build script.
Also: I need to override compile_c anyway to insert the feature defines,
unless I put the defines in a generated header file. Also also: either
way, I need to override compile_c to process the dependency of the object
file on the file that stores the probe results (either the current cache
file or the hypothetical header file).
>You could "get your own",
Wouldn't be properly configured. I want specifically the CBuilder as
configured by Module::Build under the influence of arguments passed to
Build.PL and Build (which I don't need to know the details of).
> though I'm not really sure why _cbuilder()
>shouldn't be public.
That would satisfy me about the validity of what I'm doing. The
question is whether the fact that M::B's C compilation is done via
ExtUtils::CBuilder (or a compatible class) is an architectural issue
that is right to expose. I tend to think yes on that, and in fact there
could be some interesting tricks performed by overriding ->cbuilder.
> If anything, maybe we just make sure it
>throws an exception:
Two of the three calls to ->_cbuilder already do the test and exception.
They can change to use the exception-throwing ->cbuilder. The third,
in have_c_compiler, can sensibly wrap ->cbuilder in an eval { } instead.
No need for the non-exception-throwing ->_cbuilder interface to stay
around.
>that generic enough to make it part of the M::B API,
I'm not yet sufficiently clear on what the right generalisation is for
feature tests. Need to play with it some more. One of the benefits of
easy subclassing is that we can do that.
I think another generalisation that is going to be needed here is that of
adding dependencies over the default. Not sure about a good interface
for that either, yet. It wouldn't be too difficult to effectively
reimplement make, but I think we can do better than that, and make it
more dynamic as well as achieving that generality.
-zefram
