On Feb 11, 2014, at 9:46 AM, Ryan Schmidt <ryandes...@macports.org> wrote:
>
> On Feb 6, 2014, at 11:30, mm...@macports.org wrote:
>
>> Revision
>> 116766
>> Author
>> mm...@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
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
