[116766] trunk/dports/science/ompl/Portfile

[Mark Moll]

On Feb 11, 2014, at 9:46 AM, Ryan Schmidt <ryandesign at macports.org> wrote:

> 
> On Feb 6, 2014, at 11:30, mmoll at macports.org wrote:
> 
>> Revision
>> 116766
>> Author
>> mmoll at macports.org
>> Date
>> 2014-02-06 09:30:22 -0800 (Thu, 06 Feb 2014)
>> Log Message
>> 
>> science/ompl: add missing build dependency
>> Modified Paths
>> 
>> 	• trunk/dports/science/ompl/Portfile
>> Diff
>> 
>> Modified: trunk/dports/science/ompl/Portfile (116765 => 116766)
>> 
>> --- trunk/dports/science/ompl/Portfile	2014-02-06 16:52:52 UTC (rev 116765)
>> +++ trunk/dports/science/ompl/Portfile	2014-02-06 17:30:22 UTC (rev 116766)
>> 
>> @@ -21,6 +21,7 @@
>> 
>>                     sha1    4772b9d3442f910d4d7bd3aa6e3615e8397fab88 \
>> 
>>                     rmd160  6deeb1a4664a49051961498cd0027d07936ab4cc
>> 
>> distname            ${name}-${version}-Source
>> 
>> +depends_build-append llvm-gcc42
> 
> How does ompl use llvm-gcc42? Would the Xcode version of llvm-gcc42 be sufficient, on those Xcode versions that include it?
> 
> I see that macports-llvm-gcc-4.2 is in compiler.blacklist so there’s something unusual here.

Yes, it is rather unusual. OMPL uses Py++ to generate python bindings. Py++ uses gccxml-devel. Gccxml “simulates” other compilers and generates XML files instead of object files. It cannot simulate clang. For the code that Py++ generates it doesn’t seem to matter that gccxml simulated a different compiler than the one that is eventually used to compile the python bindings. Perhaps a better approach is to define a number of variants for gccxml-devel, one for each compiler that it can simulate?

gccxml-devel can be *compiled* with many compilers, but can only *simulate* a subset of those compilers. By default it simulates the compiler that was used to compile it.
 
-- 
Mark Moll