On Mon, Jul 20, 2015 at 11:51 PM, Ryan Schmidt <ryandes...@macports.org>
wrote:
> On Jul 20, 2015, at 6:20 PM, ebori...@macports.org wrote:
> >
> > Revision
> > 138813
> > Author
> > ebori...@macports.org
> > Date
> > 2015-07-20 16:20:10 -0700 (Mon, 20 Jul 2015)
> > Log Message
> >
> > libomp: New port; LLVM project's OpenMP runtime.
>
> > Added: trunk/dports/lang/libomp/Portfile (0 => 138813)
>
> > +name libomp
> > +version 0.0
> > +revision 242604
>
> > +svn.revision ${revision}
>
> revision and svn.revision are not meant to be the same thing. revision is
> meant to be MacPorts-specific, independent of any upstream versioning. It
> is meant to be an integer that starts at 0 for every version of the port,
> and is incremented by 1 every time the port needs to be rebuilt but the
> upstream version has not changed.
>
I understand; but as there isn't currently a 'release' of the upstream
project (but I assume there will be at some point in the future) I'm just
tracking their SVN revisions; seemed like a logical thing to do until they
actually 'release.' I concede your point that this isn't the intended
design -- and my intention is to move away from it as soon as possible
(once a release exists.) I didn't want to start making (bogus) version
numbers only to have to revert to an epoch once upstream has a version
number. Not fixed / hoping upstream cuts a release and it goes away. ;)
> > +notes {
> > + Use with llvm-3.7/clang-3.7 (BOTH BUILT WITH THE '-assertions'
> VARIANT) via:
> > + -I${prefix}/include -L${prefix}/lib -fopenmp=libomp
> > +}
>
> Variables are not interpolated within strings delimited by curly braces {}.
>
Yep. Patched up for lint without re-checking output. Fixed in r138841.
> The wording "built with the '-assertions' variant" is confusing. Did you
> mean: "with the assertions variant enabled" (in other words: +assertions)
> or "with the assertions variant disabled" (in other words: -assertions)?
>
Changed wording in r138841.
> If this port requires that the llvm-3.7/clang-3.7 ports are built with (or
> without) a particular variant, that should be enforced by using the
> require_active_variants proc in the active_variants 1.1 portgroup.
>
It does not require 3.7 at all to be *built* -- you can happily build it
with 3.3-3.7. To actively *use* it (in compilation; header + dylib) 3.7 is
required with '-assertions' -- at least in my testing. One can, however,
compile and link with 3.7 and libomp, and then uninstall 3.7 and still
*use* it (dylib) with the compiled program. So it's a bit of an odd case of
a library requiring a particular compiler -- but only when the library is
being used in the compilation & linking steps something else.
It's not depends_build or even depends_run, then, on 3.7. It would make the
most sense to have an +openmp (conflicts with +assertions) variant for
{llvm,clang}-3.7 which depends_run on libomp (which would then certainly
need to not depend on llvm-3.7) ... It's also a possibility that it will be
absorbed into llvm/clang builds at some point; I'm not crystal clear on
what llvm's (the project) plan is.
I made the Portfile so I could kick the tires of Clang's
(Intel-contributed) OpenMP implementation. I thought others might find it
useful for development/testing.
- Eric
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
