On Sat, Mar 31, 2012 at 12:15 PM, Nick Wellnhofer <[email protected]> wrote: > Attached is a modified version of Lucy::Build that I use for testing.
Haha, the fact that our Clownfish autogenerated code won't compile without -std=gnu99 under GCC or /TP under MSVC hadn't crossed my mind. That would be annoying for extension authors to have to deal with, all right. > There are only minor changes to the code I copied from Lucy::Build, so > Lucy::Build could also subclass the new Clownfish build class. Ooo, *great* idea! We can build up Clownfish::CFC::Perl::Build first while breaking out Lucy, then refine and improve it while breaking out other C extension packages packages, e.g. LucyX::Search::MockMatcher. >>> 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? > > > We could add all the Clownfish build parameters as additional Module::Build > properties (see > https://metacpan.org/module/Module::Build::API#add_property). My idea is > that it might be more maintainable to only add a single property that points > to a separate config object. Then we can add new parameters without touching > Module::Build internals, for example. +1 for a separate config object as a single property. > So an extension's Build.PL would look something like this: > > my $cf_build_config = Clownfish::CFC::BuildConfig->new( > parcel => 'MyParcel', > c_sources => 'additional/c/sources', > install_files => { > 'core/My/Header.h' => 'My/Header.h', > } > ... > ); > > my $builder = Clownfish::CFC::Build->new( > module_name => 'LucyX::My::Extension', > dist_abstract => 'My Lucy extension', > ... > clownfish_config => $cf_build_config, > ); > > $builder->create_build_script; +1 for this basic architecture. The details of some individual arguments, I'd like to go over later. For example, I'd really like to improve Clownfish parcels by adding version numbers and fully-qualified domain-based namespaces while it's still easy to make changes. Marvin Humphrey
