[138813] trunk/dports/lang

[Eric A. Borisch]

On Mon, Jul 20, 2015 at 11:51 PM, Ryan Schmidt <ryandesign at macports.org>
wrote:

> On Jul 20, 2015, at 6:20 PM, eborisch at macports.org wrote:
> >
> > Revision
> > 138813
> > Author
> > eborisch at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20150721/7c474f0d/attachment.html>