On Thu, Mar 29, 2012 at 2:47 PM, Nick Wellnhofer (Commented) (JIRA) <[email protected]> wrote: > > [ > https://issues.apache.org/jira/browse/LUCY-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241830#comment-13241830 > ] > > Nick Wellnhofer commented on LUCY-215: > -------------------------------------- > > As previously discussed on the mailing list, we should also provide parts of > the code in buildlib/Lucy/Build.pm as a Clownfish module, so extensions can > be built easily.
So the idea here is that we need a class to help extension authors do stuff like install their .cfh header files into $installsitearch/Clownfish/_include because we don't want them to have to write low-level code to do that themselves. Perhaps it would be helpful to see a hacked-up, monotlithic extension build script that does all the necessary work to build and install a Lucy C extension, no matter how dirty the implementation. Then we can create a helper class and beef it up bit by bit while whittling down the build script until things look reasonable. > To handle different build configuration variables like > module name, additional C sources, etc., I would propose to create a > BuildConfig class that provides all these variables via methods. Then, every > extensions can optionally extend the class and create a BuildConfig object. > This object can be stored as a "property" of the Module::Build object. > Build configuration includes: > > * Main class name > * Parcel > * Additional C sources, include dirs and flags > * Additional libraries and linker flags > * Clownfish include directories > * Other files to install in Clownfish/_include This BuildConfig class is separate from the build class, right? And the idea is that they won't have to subclass the build class, because specifying properties in the BuildConfig class will suffice for all customization needs? > Open questions: > > * How to name the build module? Clownfish::CFC::Build? Presumably we're going to need analogous functionality for other languages -- but the implementation of e.g. our Ruby-specific extension build helper is going to be very different from this one. Even if Clownfish::CFC::Build's Perl-specific functionality is written entirely in Perl and it's Ruby-specific functionality is written entirely in Ruby, it sounds undesirable to have radically divergent classes under the same name. How about Clownfish::CFC::Perl::Build instead? Another possibility is Clownfish::CFC::Binding::Perl::Build, but that seems long. (And perhaps the fact that it seems long suggests that "Binding" should be deleted from other similar classes, e.g. Clownfish::CFC::Perl::Class instead of Clownfish::CFC::Binding::Perl::Class.) > * We might need a better way to find the Binding build packages. Can you please elaborate? I'm not grokking... > * Should we support parts of the Valgrind infrastructure? Possibly, but Valgrind support is really hard to get right across multiple operating systems, host languages and versions of Valgrind itself. We won't want the test suite to fail if something goes haywire. :) Marvin Humphrey
