<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jul 20, 2015 at 11:51 PM, Ryan Schmidt <span dir="ltr"><<a href="mailto:ryandesign@macports.org" target="_blank">ryandesign@macports.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On Jul 20, 2015, at 6:20 PM, <a href="mailto:eborisch@macports.org">eborisch@macports.org</a> wrote:<br>
><br>
> Revision<br>
> 138813<br>
> Author<br>
> <a href="mailto:eborisch@macports.org">eborisch@macports.org</a><br>
> Date<br>
> 2015-07-20 16:20:10 -0700 (Mon, 20 Jul 2015)<br>
> Log Message<br>
><br>
> libomp: New port; LLVM project's OpenMP runtime.<br>
<br>
> Added: trunk/dports/lang/libomp/Portfile (0 => 138813)<br>
<br>
> +name libomp<br>
> +version 0.0<br>
> +revision 242604<br>
<br>
> +svn.revision ${revision}<br>
<br>
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.<br></blockquote><div><br></div><div>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. ;)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">> +notes {<br>
> + Use with llvm-3.7/clang-3.7 (BOTH BUILT WITH THE '-assertions' VARIANT) via:<br>
> + -I${prefix}/include -L${prefix}/lib -fopenmp=libomp<br>
> +}<br>
<br>
Variables are not interpolated within strings delimited by curly braces {}.<br></blockquote><div><br></div><div>Yep. Patched up for lint without re-checking output. Fixed in r138841.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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)?<br></blockquote><div><br></div><div>Changed wording in r138841.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div> - Eric</div></div><br></div></div>