Steffen Mueller wrote: > Hi all, > > Mattia Barbon wrote: >> As noted in one of the answers, wxPerl only guesses the C++ compiler >> on Windows, and here you only have 3 Perl-supported alternatives (MSVC, >> MinGW, Borland). OS X is easy too (AFAIK Perl only supportes GCC). On >> the various unices you can probably use a big rule set, matching the C >> compiler name and/or some other heuristics. IME it is the kind of thing >> that is easy to get 99% right. > > This must seem easy to you because you know all this and apparently have > access to multiple compilers and platforms. I believe being able to do > this 99% right is very much dependent on experience. Thus it would be a > very good candidate for being solved once by experts and reused by fools > like myself.
Agreed, I am just saying that is just a (not big, not complex) ruleset; it is not something that requires coding-fu. >> Another interesting information is binary compatibility between >> versions. For example GCC changed ABI 3 times between 3.0 and 3.4, and >> MSVC uses a different C/C++ runtime for every release from 6.0 to 9.0, >> and IIRC recent MinGW releases switched exception handling to DWARF, so >> they are incompatible with older versions. > > I guess if you replace the compiler of a system with an incompatible > one, you're asking for trouble anyway. I don't see how we could possibly > do anything about that. I'm not saying you can make the problem of incompatible compilers go away, but remmeber that as a module author you tend to be on the receiving end of the trouble... Take this smoke report as an example: http://www.cpantesters.org/cpan/report/07250778-b19f-3f77-b713-d32bba55d77f An XCode update switched 'g++' from 3.3 to 4.0. It took a couple of hours to figure it out, and just because I had physical access to a PPC OS X installation. Besides, as a user, I'd like a clear error message rather than a compile/link/runtime error. >> And I'd like a way to guess the C++ compiler that was used to build a >> binary (using embedded strings, linked libraries, ...). > > That would be nice. Another thing I'd like (even more, actually) is > guessing the C++ compiler from the C compiler that was used to compiler > Perl. Me too; actually, I was putting it with the "99% right" part above. > What information I found on CPAN is mostly from Inline::CPP: > http://search.cpan.org/~neilw/Inline-CPP-0.25/lib/Inline/CPP.pod#Choosing_a_C++_Compiler > > and http://cpansearch.perl.org/src/NEILW/Inline-CPP-0.25/Makefile.PL > > If we could make these simple guesses into a super-simple module (maybe > even shipped with EU::XSpp) that provides a better first guess than > "g++", we'd probably be in a much more portable position already. One > could always add some fancy option to parse a "standard" set of > arguments to Makefile.PL/Build.PL to give control to users where necessary. > > The interface could be something like or a subset of: > > use ExtUtils::CppGuess; > > my $guess = ExtUtils::CppGuess->new; > my $cc = $guess->from_cli(\...@argv) > // $guess->from_library("-lwx") > // $guess->from_config; > > I'm the least qualified to do this. Are there any takers? I'll take it. I'll probably make it a separate distribution (but have no strong opinion on that). Regards, Mattia _______________________________________________ Padre-dev mailing list Padre-dev@perlide.org http://mail.perlide.org/mailman/listinfo/padre-dev
