Add support for setting compiler options using ExtUtils::Depends

[zmughal]

This will make it easier to pull in the compiler flags by just using the name of the relevant package (e.g., PDL, Gimp, Leptonica, etc.). Plus, all Alien::Base packages have support for this right now.

CC: @Perl5-Alien

[run4flat]

@zmughal, this is on the list in my head, and now it's officially on my list in this queue. FWIW, compiler setup API is going to be my main focus once C::Blocks hits beta, i.e. once it's passing its tests on all platforms. Until then it will not be much of a priority, which gives us some time to work out some of the details of the API. My current ideas are detailed below. Please comment with how you think this will work, or not work.

The current kludgey method for setting compiler options involves a BEGIN block before your cblock which sets a few special variables. See the begin block in my libprima example: https://github.com/run4flat/C-Blocks/blob/e0ac9846a3b68cf83f4056c23f952083ecaa97e1/examples/libprima.pm. Those package variables are queried and reset as soon as the first cblock, cshare, clex, or csub is encountered. Furthermore, this only allows for a single shared library to be associated with any given block. If you have multiple libraries that you want to expose to a single cblock of actionable code, then you would write a separate clex or cshare block for each library, pulling in all of the appropriate headers.

At the moment, my next idea is to revise the import method of C::Blocks. It would accept a hashref, a package name, an object, and possibly other things. (1) If a hashref, it would include structured data for include and library directories, compiler options, and libraries to import. (2) If a package name, the package would have package methods that return data structured in a way similar to (1). (3) If an object, it would have object methods that return data structured in a way similar to (1).

The hashref usage might look like this:

use C::Blocks {
    include => [ 'some/dir', 'other/dir' ],
    libdirs => ['path/to/lib/dir'],
    libs => ['lib1', 'lib2'],
};
clex {
    #include "important_lib.h"
}
use C::Blocks; # clear out settings

The package usage would look like this:

package My::C::Blocks::Config;
sub include { [ 'some/dir', 'other/dir' ] }
sub libdirs { ['path/to/lib/dir'] }
sub libs { ['lib1', 'lib2'] }

package My::C::Blocks::Code;
use C::Blocks qw(My::C::Blocks::Config);
clex {
    #include "important_lib.h"
}
use C::Blocks; # clear out settings

The object process would be similar, except you would say something like

use C::Blocks My::C::Blocks::Config->new(arg1, arg2);

The advantage to the object or package approach is that somebody else could easily subclass your configuration. This is particularly important if/when I provide code modification hooks.

So, how would this work with ExtUtils::Depends? The "and possibly other things" mentioned above is key. Perhaps the use statement could take two arguments for common dependency builders, which I would have to special-case for. Thus, I could add support for:

use C::Blocks eud => 'Gimp';

[run4flat]

Paging all those who are interested -- I am about to begin work on this kinda stuff. Now is the time to let me know if you have any ideas, suggestions, or proposals. :-)

[zmughal]

None at the time, but I'll gladly help test the code!

---

By the way, I noticed your thread on perl-xs and can confirm the Windows build problems, but didn't have time to look further yesterday.