FYI: Inline::CPP v0.39 released

[David Oswald]

I've uploaded Inline::CPP v0.39 to CPAN.

This version includes everything from 0.38_004 (dev), plus some new
tests such as Test::POD::Coverage, and Test::Kwalitee. It also
includes a lot of refactoring following Michael Schwern's "Skimmable
Code" talk's suggestions. The refactoring is still a work in progress
(info(), wrap() are next), with a goal of rendering the code easier to
work with in the future. Additionally there have been some
adjustments to Makefile.PL targeting more thorough META.* files
(dependencies, license, minimum Perl version). Configuration
information is also no longer written directly to CPP.pm. Now it's
written to Inline::CPP::Config.pm which is used by CPP.pm. It just
seemed cleaner.

The reasons for releasing 0.39 as opposed to another dev release
essentially all boil down to it being a good place to plant ones feet
before moving on to new development tracks:

Testing seems to have stabilized: We're not breaking anything new
(famous last words?).

There have been a lot of code quality improvements that needn't be
held back from general use.

I want to start a new development track working on refactoring the
compiler and libs guess logic in Makefile.PL, and want to establish
v0.39 as a usable base in case my Makefile.PL refactoring breaks
something in an upcoming dev release.



By the way: Does anyone know a "best practice" for where example code
should go within a distribution? ./examples/ perhaps?

[Sisyphus]

----- Original Message -----
From: "David Oswald" <daoswald-***@public.gmane.org>
To: <inline-***@public.gmane.org>
Sent: Monday, May 07, 2012 6:08 PM
Subject: FYI: Inline::CPP v0.39 released

Post by David Oswald
I've uploaded Inline::CPP v0.39 to CPAN.

No problems here - it works fine for all my MinGW-built perls.

I've just uploaded InlineX-CPP2XS-0.21, which now has the capability of
writing a portable Makefile.PL and xs file - by specifying WRITE_MAKEFILE_PL
=> 'p' (or --write_makefile_pl=p if you use the cpp2xs utility).

The test script (t_portability.t) uses the Math::Primes::FastSieve demo to
do some checking. It just checks that the expected files are generated, and
does some sanity checks on them.

One thing I noticed in CPP.pm's validate subroutine is that it does:

#################################
$o->{ILSM}{AUTO_INCLUDE} ||= $auto_include;
$o->{ILSM}{AUTO_INCLUDE} = $flavor_defs . $o->{ILSM}{AUTO_INCLUDE};
#################################

(You've probably always done it that way - I haven't checked.)

For the purposes of InlineX::CPP2XS (and perhaps other purposes, too), it
would make things easier if it did:

#################################
$o->{ILSM}{AUTO_INCLUDE} ||= $flavor_defs . $auto_include;
#################################

But I don't know whether that fixes a bug in validate(), or creates one, or
does neither.
As regards the tests in the I::CPP test suite it seems we can do it either
way, and it makes no difference.

In case you haven't spotted the relevance, validate() will currently always
prepend auto_include with $flavor_defs. But you can avoid that if you use
the latter.
And, for portability, we don't want the contents of $flavor_defs to appear
anywhere in the shipped C++ source code - hence the relevance to
InlineX::CPP2XS.

(Btw, don't stress about this .... I already have "workarounds" in place,
anyway :-)

Cheers,
Rob