On Fri, Mar 23, 2012 at 10:49 PM, David Oswald <daosw...@gmail.com> wrote: > I maintain Inline::CPP. Currently that module's Makefile.PL jumps > through a bunch of hoops to detect the C++ compiler most compatible > with the C compiler that built perl, and to detect what default C++ > libraries should be linked in when building Inline::CPP client code. > A lot of work has gone into tweaking to obtain better success rates > with as wide a variety of platforms as possible. > > This work could be applicable to other modules that wish to build XS > code based on C++. Additionally, I would like the ability to continue > development (there's a lot of work still to do) on this task > independently of Inline::CPP (I don't like uploading a new Inline::CPP > for smoke testing every time I want to smoke test a change to > Makefile.PL while leaving the core modules virtually unchanged). > > So I intend to split this functionality out of Inline::CPP's > Makefile.PL by creating a new module to handle the detection/guessing > logic. > > That begs the question of what to call it. "Config" already reveals > information about how Perl was built (C compiler, etc.). This is > essentially an extension of that functionality. Therefore, it makes > sense to me to call it something like "Config::CPP". But > unfortunately, Config shares its top-level namespace with modules that > are used to deal with configuration files (Config::Auto, > Config::General, Config::JSON, etc.). > > My question is what would be an appropriate name for this module?
This sounds very similar to ExtUtils::CppGuess. If you don't want to merge it with that, something in the ExtUtils namespace would be appropriate IMO. Leon