patch feedback:depends_test - port test - port lint -append

[Kurt Hindenburg]

Hi,
  Can I get some feedback on these patches?

https://trac.macports.org/ticket/38208  
- add depends_test
https://trac.macports.org/ticket/45010  
- port test stops if test.run is not yes
https://trac.macports.org/ticket/28640  
- port lint check when should use -append

Thanks,
 Kurt___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Trac seems to be up again!

[Aljaž]

It looks up from Italy, too. Yay!

Aljaž Srebrnič

Sent from mobile
-- --
My public key: http://bit.ly/81qoyC

> On 03/set/2015, at 22:10, petr <9...@ingv.it> wrote:
> 
> Trac is seems to talk to us again.
> Party!
> ~petr
> 
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Trac seems to be up again!

[petr]

Trac is seems to talk to us again.
Party!
~petr

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: svn commit access down again this morning

[Daniel J. Luke]

Worked for me just now (using the new subversion 1.9.1 that I just committed in 
r139932)

> On Sep 3, 2015, at 1:31 PM, Michael Dickens  wrote:
> Hasn't worked for me since yesterday sometime. Definitely not any time
> today (Thursday). I even tried manually entering in my (20 character)
> random password (PITA) without success (didn't work with cut-and-paste
> either, to be fair). Just gave up for now. - MLD
> 
> On Thu, Sep 3, 2015, at 01:27 PM, Daniel J. Luke wrote:
>> On Sep 3, 2015, at 1:08 PM, David Evans  wrote:
>>> Authenication is failing on svn commits for me again this morning.  
>> 
>> I believe I'm seeing this too (but I’m trying with my newly updated
>> subversion 1.9.1, so I could be seeing a subversion bug). I’ll stop
>> attempting to debug until someone confirms svn.macports.org is working
>> correctly.

--
Daniel J. Luke  
 
++  
  
| * dl...@geeklair.net * |  

| *-- http://www.geeklair.net -* |  

++  
  
|   Opinions expressed are mine and do not necessarily   |  

|  reflect the opinions of my employer.  |  

++



___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: llvm-3.7 release and OpenMP

[Jeremy Huddleston Sequoia]

> On Sep 3, 2015, at 10:51, Sean Farley  wrote:
> 
> 
> Jeremy Huddleston Sequoia  writes:
> 
>>> On Sep 3, 2015, at 10:32, Sean Farley  wrote:
>>> 
>>> 
>>> Jeremy Huddleston Sequoia  writes:
>>> 
> On Sep 3, 2015, at 09:21, Jack Howarth  
> wrote:
> 
> You really will want to rewrite the llvm37 Portfile to use a cmake
> build.
 
 Not unless we can depend on cmake existing out-of-tree.  If we need to 
 depend on port:cmake, that introduces cycles.
>>> 
>>> 
>>> How? I only see these as dependencies for cmake:
>>> 
>>> $ port rdeps cmake
>>> The following ports are dependencies of cmake @3.3.1_0:
>>> curl
>>>   pkgconfig
>>> libiconv
>>>   gperf
>>>   zlib
>>> xz
>>>   gettext
>>> expat
>>> ncurses
>>>   openssl
>>>   curl-ca-bundle
>>> perl5
>>>   perl5.16
>>> gdbm
>>> bzip2
>>> libarchive
>>>   libxml2
>>>   lzo2
>>> 
>>> I see that libomp depends on cmake but cmake doesn't depend on libomp
>>> nor llvm so how is it a cycle?
>> 
>> You're not looking at build dependencies.
>> 
>> On older OS veersions, cmake requires either macports-clang-X.Y (for libc++ 
>> clients) or macports-gcc-X.Y (for libstdc++ clients) to compile due to its 
>> C++11 requirement.
> 
> Ah, I see more dependencies now. The only C++11 requirements I see
> though are with the 'gui' variant. So, wouldn't we be able to depend on
> 'cmake -gui' or am I missing something else?

We don't have support for expressing that well in base, so I'm just very 
conservative about bringing in any dependencies into the toolchain.  I'm happy 
to add non-default variants to llvm and clang, but adding a new dependency 
(especially one that can bring in both perl and python) is a bit scary. =/

Note that building a newer toolchain on Tiger is a bit of a challenge, and we 
ended up using a +bootstrap variant in the apple-gcc42 port to help out with 
that, but I'd prefer not to have to resort to such tactics for more recent OS 
versions.  Specifically, I'd prefer to not have to tell people to install cmake 
-gui, then clang-3.7, then cmake with their desired variants.

I guess it would be ok to have such users use clang-3.4 to build cmake to build 
clang-3.8, but that's also sub-optimal.  I'm certainly not against it, though, 
since it is only an issue for older OS versions.

If you (or someone else) wants to take a shot at this, please do so.  I think 
at minimum, we'd need to:
a) Update the llvm-3.8 port with a dependency on port:cmake and relevant 
other changes
b-1) Update the cmake port to check if clang-3.8 is installed and blacklist 
it if it isn't
b-2) Come up with a better way (in base) of ensuring that a compiler is not 
used to satisfy its own dependencies if it is not already installed

--Jeremy



smime.p7s
Description: S/MIME cryptographic signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: llvm-3.7 release and OpenMP

[Sean Farley]

Jeremy Huddleston Sequoia  writes:

>> On Sep 3, 2015, at 10:32, Sean Farley  wrote:
>> 
>> 
>> Jeremy Huddleston Sequoia  writes:
>> 
 On Sep 3, 2015, at 09:21, Jack Howarth  
 wrote:
 
  You really will want to rewrite the llvm37 Portfile to use a cmake
 build.
>>> 
>>> Not unless we can depend on cmake existing out-of-tree.  If we need to 
>>> depend on port:cmake, that introduces cycles.
>> 
>> 
>> How? I only see these as dependencies for cmake:
>> 
>> $ port rdeps cmake
>> The following ports are dependencies of cmake @3.3.1_0:
>>  curl
>>pkgconfig
>>  libiconv
>>gperf
>>zlib
>>  xz
>>gettext
>>  expat
>>  ncurses
>>openssl
>>curl-ca-bundle
>>  perl5
>>perl5.16
>>  gdbm
>>  bzip2
>>  libarchive
>>libxml2
>>lzo2
>> 
>> I see that libomp depends on cmake but cmake doesn't depend on libomp
>> nor llvm so how is it a cycle?
>
> You're not looking at build dependencies.
>
> On older OS veersions, cmake requires either macports-clang-X.Y (for libc++ 
> clients) or macports-gcc-X.Y (for libstdc++ clients) to compile due to its 
> C++11 requirement.

Ah, I see more dependencies now. The only C++11 requirements I see
though are with the 'gui' variant. So, wouldn't we be able to depend on
'cmake -gui' or am I missing something else?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Upgrading rust to 1.2.0

[Sean Farley]

I've been looking at rust and thought I'd upgrade it to 1.2.0. I think
the bootstrapping is no longer needed since version 1.0 (the one we were
using was old as well).

Here is the patch I've come up with for upgrading. I was hoping to get
some feedback from those that know rust better than I. Thanks!


# HG changeset patch
# User Sean Farley 
# Date 1441301774 25200
#  Thu Sep 03 10:36:14 2015 -0700
# Node ID 7e8d821769e7bd4fd3083688841bc505afe5e779
# Parent  b7d548b79f4fec0a1126d3a47e96c12584ff975e
rust: update to 1.2.0 and prefer clang

This also drops the code to download a specific staging distribution because
rust has been able to do that since 1.0.0.

diff --git a/dports/lang/rust/Portfile b/dports/lang/rust/Portfile
--- a/dports/lang/rust/Portfile
+++ b/dports/lang/rust/Portfile
@@ -4,11 +4,11 @@
 PortSystem  1.0
 PortGroup   active_variants 1.1
 PortGroup   compiler_blacklist_versions 1.0
 
 namerust
-version 1.0.0
+version 1.2.0
 categories  lang devel
 platforms   darwin
 supported_archs i386 x86_64
 # https://github.com/mozilla/rust/issues/2024
 universal_variant   no
@@ -37,43 +37,18 @@ pre-fetch {
 # snapshot compiler, we let base treat it as the distfile and deal with
 # the actual Rust source "manually".
 
 # Download the snapshot compiler; see src/snapshots.txt in the Rust
 # distribution.
-master_siteshttps://static.rust-lang.org/dist/:main \
-https://static.rust-lang.org/stage0-snapshots/:snap
+master_siteshttps://static.rust-lang.org/dist/:main
 
 distfiles   ${name}c-${version}-src${extract.suffix}:main
 worksrcdir  ${name}c-${version}
 
 checksums   ${name}c-${version}-src${extract.suffix} \
-rmd160  b1127e616619fcd981e33896d4f00c4bf548ce6b \
-sha256  
c304cbd4f7b25d116b73c249f66bdb5c9da8645855ce195a41bda5077b995eba
-
-set stage0(distdir) rust-stage0
-set stage0(date)2015-03-27
-set stage0(rev) 5520801
-set stage0(platform)macos-${configure.build_arch}
-set stage0(hash)[expr {${configure.build_arch} eq "i386" ?
-"0310b1a970f2da7e61770fd14dbbbdca3b518234" :
-"5f35d9c920b8083a7420ef8cf5b00d5ef3085dfa"}]
-
-set stage0_name [join "rust stage0 ${stage0(date)}
-   ${stage0(rev)}
-   ${stage0(platform)}
-   ${stage0(hash)}" -].tar.bz2
-
-distfiles-append${stage0_name}:snap
-
-switch ${configure.build_arch} {
-i386{checksums-append   ${stage0_name} \
-rmd160  15a0ffbcee0def1a056d69aa851edf2b8ca490b6 \
-sha256  
0cc20c5f3c808d6332bcc192b60d6a1e9ee313d481030d8d07ff42a831492ba2}
-default {checksums-append   ${stage0_name} \
-rmd160  a5ef6ad68e6e49b40d045e45227ad858b0935988 \
-sha256  
38076751be5a52a61285cced36879832a7a106d7ce0bfd2b2080c3cfc42de1ce}
-}
+rmd160  83a98c67a0aca97467d21150fa6a95fc77d10cc1 \
+sha256  
ea6eb983daf2a073df57186a58f0d4ce0e85c711bec13c627a8c85d51b6a6d78
 
 # Only use compilers supported by upstream
 # (https://github.com/rust-lang/rust#building-from-source).
 compiler.blacklist  {clang < 211} \
 *dragonegg* \
@@ -112,13 +87,12 @@ if {${configure.build_arch} eq "i386"} {
 # We need to use "--enable-rpath" as of a0546de, otherwise the build
 # produces improperly linked binaries.
 # (https://github.com/rust-lang/rust/issues/11747)
 # TODO: Build docs also, probably in a subport.
 configure.args  --disable-docs \
---enable-local-rust \
 --enable-rpath \
---local-rust-root=${workpath}/${stage0(distdir)}
+--enable-clang
 
 build.type  gnu
 build.args  VERBOSE=1 \
 CC=${configure.cc} \
 CXX=${configure.cxx} \
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: llvm-3.7 release and OpenMP

[Jeremy Huddleston Sequoia]

> On Sep 3, 2015, at 10:32, Sean Farley  wrote:
> 
> 
> Jeremy Huddleston Sequoia  writes:
> 
>>> On Sep 3, 2015, at 09:21, Jack Howarth  
>>> wrote:
>>> 
>>>  You really will want to rewrite the llvm37 Portfile to use a cmake
>>> build.
>> 
>> Not unless we can depend on cmake existing out-of-tree.  If we need to 
>> depend on port:cmake, that introduces cycles.
> 
> 
> How? I only see these as dependencies for cmake:
> 
> $ port rdeps cmake
> The following ports are dependencies of cmake @3.3.1_0:
>  curl
>pkgconfig
>  libiconv
>gperf
>zlib
>  xz
>gettext
>  expat
>  ncurses
>openssl
>curl-ca-bundle
>  perl5
>perl5.16
>  gdbm
>  bzip2
>  libarchive
>libxml2
>lzo2
> 
> I see that libomp depends on cmake but cmake doesn't depend on libomp
> nor llvm so how is it a cycle?

You're not looking at build dependencies.

On older OS veersions, cmake requires either macports-clang-X.Y (for libc++ 
clients) or macports-gcc-X.Y (for libstdc++ clients) to compile due to its 
C++11 requirement.

--Jeremy



smime.p7s
Description: S/MIME cryptographic signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: llvm-3.7 release and OpenMP

[Sean Farley]

Jeremy Huddleston Sequoia  writes:

>> On Sep 3, 2015, at 09:21, Jack Howarth  wrote:
>> 
>>   You really will want to rewrite the llvm37 Portfile to use a cmake
>> build.
>
> Not unless we can depend on cmake existing out-of-tree.  If we need to depend 
> on port:cmake, that introduces cycles.


How? I only see these as dependencies for cmake:

$ port rdeps cmake
The following ports are dependencies of cmake @3.3.1_0:
  curl
pkgconfig
  libiconv
gperf
zlib
  xz
gettext
  expat
  ncurses
openssl
curl-ca-bundle
  perl5
perl5.16
  gdbm
  bzip2
  libarchive
libxml2
lzo2

I see that libomp depends on cmake but cmake doesn't depend on libomp
nor llvm so how is it a cycle?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: svn commit access down again this morning

[Michael Dickens]

Hasn't worked for me since yesterday sometime. Definitely not any time
today (Thursday). I even tried manually entering in my (20 character)
random password (PITA) without success (didn't work with cut-and-paste
either, to be fair). Just gave up for now. - MLD

On Thu, Sep 3, 2015, at 01:27 PM, Daniel J. Luke wrote:
> On Sep 3, 2015, at 1:08 PM, David Evans  wrote:
> > Authenication is failing on svn commits for me again this morning.  
> 
> I believe I'm seeing this too (but I’m trying with my newly updated
> subversion 1.9.1, so I could be seeing a subversion bug). I’ll stop
> attempting to debug until someone confirms svn.macports.org is working
> correctly.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: svn commit access down again this morning

[Daniel J. Luke]

On Sep 3, 2015, at 1:08 PM, David Evans  wrote:
> Authenication is failing on svn commits for me again this morning.  

I believe I'm seeing this too (but I’m trying with my newly updated subversion 
1.9.1, so I could be seeing a subversion bug). I’ll stop attempting to debug 
until someone confirms svn.macports.org is working correctly.

--
Daniel J. Luke  
 
++  
  
| * dl...@geeklair.net * |  

| *-- http://www.geeklair.net -* |  

++  
  
|   Opinions expressed are mine and do not necessarily   |  

|  reflect the opinions of my employer.  |  

++




___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: llvm-3.7 release and OpenMP

[Jeremy Huddleston Sequoia]

> On Sep 3, 2015, at 09:21, Jack Howarth  wrote:
> 
>   You really will want to rewrite the llvm37 Portfile to use a cmake
> build.

Not unless we can depend on cmake existing out-of-tree.  If we need to depend 
on port:cmake, that introduces cycles.

--Jeremy

> The openmp 3.7 can be built in-tree using cmake (with the
> sources placed at projects/openmp. Also the default for -fopenmp is
> still left as -fopenmp=libgomp in 3.7.0 but this can be changed
> with...
> 
> --- cfe-3.7.0.src/CMakeLists.txt.orig 2015-09-02 12:21:32.0 -0400
> +++ cfe-3.7.0.src/CMakeLists.txt 2015-09-02 12:21:51.0 -0400
> @@ -182,7 +182,7 @@
> set(DEFAULT_SYSROOT "" CACHE PATH
>   "Default  to all compiler invocations for --sysroot=." )
> 
> -set(CLANG_DEFAULT_OPENMP_RUNTIME "libgomp" CACHE STRING
> +set(CLANG_DEFAULT_OPENMP_RUNTIME "libomp" CACHE STRING
>   "Default OpenMP runtime used by -fopenmp.")
> 
> set(CLANG_VENDOR "" CACHE STRING
> 
> In fink, we set the explicit location of the buried libomp.dylib with...
> 
> --- cfe-3.7.0.src/lib/Driver/Tools.cpp.orig 2015-07-02
> 09:10:45.0 -0400
> +++ cfe-3.7.0.src/lib/Driver/Tools.cpp  2015-07-03 21:43:42.0 -0400
> @@ -6368,12 +6368,18 @@
>options::OPT_fno_openmp, false)) {
> switch (getOpenMPRuntime(getToolChain(), Args)) {
> case OMPRT_OMP:
> +  // Help clang find libomp.dylib
> +  CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
>   CmdArgs.push_back("-lomp");
>   break;
> case OMPRT_GOMP:
> +  // Help clang find libgomp.dylib
> +  CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
>   CmdArgs.push_back("-lgomp");
>   break;
> case OMPRT_IOMP5:
> +  // Help clang find libiomp5.dylib
> +  CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
>   CmdArgs.push_back("-liomp5");
>   break;
> case OMPRT_Unknown:
> @@ -8079,9 +8085,13 @@
> // Also link the particular OpenMP runtimes.
> switch (getOpenMPRuntime(ToolChain, Args)) {
> case OMPRT_OMP:
> + // Help clang find libomp.dylib
> + CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
>   CmdArgs.push_back("-lomp");
>   break;
> case OMPRT_GOMP:
> +  // Help clang find libgomp.dylib
> +  CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
>   CmdArgs.push_back("-lgomp");
> 
>   // FIXME: Exclude this for platforms with libgomp that don't require
> @@ -8089,6 +8099,8 @@
>   CmdArgs.push_back("-lrt");
>   break;
> case OMPRT_IOMP5:
> + // Help clang find libiomp5.dylib
> + CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
>   CmdArgs.push_back("-liomp5");
>   break;
> case OMPRT_Unknown:
> 
> to produce -L/sw/opt/llvm-3.7/lib on the linkage. Lastly, to build the
> fat binary of libomp,
> you need to pass cmake the flag -DLIBOMP_OSX_ARCHITECTURES="x86_64;i386".
>   Jack
> ps Note that the perl-based Makefile build is no longer functional in
> 3.7.0 and is in the process of being completely removed for the 3.8.0
> release.
> 
> On Wed, Sep 2, 2015 at 9:59 PM, Jeremy Huddleston Sequoia
>  wrote:
>> Looks good to me.  Could you go ahead and push this to svn and also do 
>> similar changes to the llvm-3.8 port for your openmp variant?
>> 
>> Thanks,
>> Jeremy
>> 
>>> On Sep 2, 2015, at 15:34, Eric A. Borisch  wrote:
>>> 
>>> Would have done a ticket, but with trac down
>>> 
>>> Attached is a patch to update to the released llvm/clang-3.7 (this comments 
>>> out the svn fetch code, removes the default +assertions, and adds checksums)
>>> 
>>> As OpenMP is one of the much discussed items that llvm-3.7 brings to the 
>>> table, I've added a +openmp variant to clang-3.7. This variants pulls in 
>>> port:libomp and sets up clang such that "-fopenmp" will use it by default. 
>>> This makes it much more likely for tools like autoconf to detect OpenMP 
>>> support. (Without the variant, openmp support is still there, but it 
>>> requires -fopenmp=libomp, which isn't in the set of standard "can we do 
>>> OpenMP" flags.) If people are supportive of it, I would suggest making it a 
>>> default variant.
>>> 
>>> Note that -I/opt/local/include and -L/opt/local/lib (assuming standard 
>>> MacPorts install location) are required with -fopenmp for things to work 
>>> and not complain about missing omp.h or -lomp.
>>> 
>>> If there is someone more familiar with clang/llvm building (of the tools 
>>> themselves), it might be interesting to consider baking in those -I/-L 
>>> flags (or move the libomp include/lib install directories so they only have 
>>> omp.h and the libomp*.dylib files and using those) so -fopenmp would "just 
>>> work." (Without the extra -I and -L)... Let me know if there is interest 
>>> and I can rework the libomp port to support this.
>>> 
>>> Thanks,
>>>  - Eric
>>> 
>> 
>> ___

Re: llvm-3.7 release and OpenMP

[Eric A. Borisch]

I'll defer on rewriting the portfile for cmake.

I guess I like having libomp separate for now as it's much quicker to
update (build) it stand-alone while it's still getting frequent
updates. Note that (apparently) llvm is also packaging the OpenMP
runtime separately for now -- see the pre-built binaries section of
http://llvm.org/releases/download.html

I like your patch to teach clang where to look -- I'll add that when I
have a chance.


On Thu, Sep 3, 2015 at 11:21 AM, Jack Howarth
 wrote:
>You really will want to rewrite the llvm37 Portfile to use a cmake
> build. The openmp 3.7 can be built in-tree using cmake (with the
> sources placed at projects/openmp. Also the default for -fopenmp is
> still left as -fopenmp=libgomp in 3.7.0 but this can be changed
> with...
>
> --- cfe-3.7.0.src/CMakeLists.txt.orig 2015-09-02 12:21:32.0 -0400
> +++ cfe-3.7.0.src/CMakeLists.txt 2015-09-02 12:21:51.0 -0400
> @@ -182,7 +182,7 @@
>  set(DEFAULT_SYSROOT "" CACHE PATH
>"Default  to all compiler invocations for --sysroot=." )
>
> -set(CLANG_DEFAULT_OPENMP_RUNTIME "libgomp" CACHE STRING
> +set(CLANG_DEFAULT_OPENMP_RUNTIME "libomp" CACHE STRING
>"Default OpenMP runtime used by -fopenmp.")
>
>  set(CLANG_VENDOR "" CACHE STRING
>
> In fink, we set the explicit location of the buried libomp.dylib with...
>
> --- cfe-3.7.0.src/lib/Driver/Tools.cpp.orig 2015-07-02
> 09:10:45.0 -0400
> +++ cfe-3.7.0.src/lib/Driver/Tools.cpp  2015-07-03 21:43:42.0 -0400
> @@ -6368,12 +6368,18 @@
> options::OPT_fno_openmp, false)) {
>  switch (getOpenMPRuntime(getToolChain(), Args)) {
>  case OMPRT_OMP:
> +  // Help clang find libomp.dylib
> +  CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
>CmdArgs.push_back("-lomp");
>break;
>  case OMPRT_GOMP:
> +  // Help clang find libgomp.dylib
> +  CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
>CmdArgs.push_back("-lgomp");
>break;
>  case OMPRT_IOMP5:
> +  // Help clang find libiomp5.dylib
> +  CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
>CmdArgs.push_back("-liomp5");
>break;
>  case OMPRT_Unknown:
> @@ -8079,9 +8085,13 @@
>  // Also link the particular OpenMP runtimes.
>  switch (getOpenMPRuntime(ToolChain, Args)) {
>  case OMPRT_OMP:
> + // Help clang find libomp.dylib
> + CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
>CmdArgs.push_back("-lomp");
>break;
>  case OMPRT_GOMP:
> +  // Help clang find libgomp.dylib
> +  CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
>CmdArgs.push_back("-lgomp");
>
>// FIXME: Exclude this for platforms with libgomp that don't 
> require
> @@ -8089,6 +8099,8 @@
>CmdArgs.push_back("-lrt");
>break;
>  case OMPRT_IOMP5:
> + // Help clang find libiomp5.dylib
> + CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
>CmdArgs.push_back("-liomp5");
>break;
>  case OMPRT_Unknown:
>
> to produce -L/sw/opt/llvm-3.7/lib on the linkage. Lastly, to build the
> fat binary of libomp,
> you need to pass cmake the flag -DLIBOMP_OSX_ARCHITECTURES="x86_64;i386".
>Jack
> ps Note that the perl-based Makefile build is no longer functional in
> 3.7.0 and is in the process of being completely removed for the 3.8.0
> release.
>
> On Wed, Sep 2, 2015 at 9:59 PM, Jeremy Huddleston Sequoia
>  wrote:
>> Looks good to me.  Could you go ahead and push this to svn and also do 
>> similar changes to the llvm-3.8 port for your openmp variant?
>>
>> Thanks,
>> Jeremy
>>
>>> On Sep 2, 2015, at 15:34, Eric A. Borisch  wrote:
>>>
>>> Would have done a ticket, but with trac down
>>>
>>> Attached is a patch to update to the released llvm/clang-3.7 (this comments 
>>> out the svn fetch code, removes the default +assertions, and adds checksums)
>>>
>>> As OpenMP is one of the much discussed items that llvm-3.7 brings to the 
>>> table, I've added a +openmp variant to clang-3.7. This variants pulls in 
>>> port:libomp and sets up clang such that "-fopenmp" will use it by default. 
>>> This makes it much more likely for tools like autoconf to detect OpenMP 
>>> support. (Without the variant, openmp support is still there, but it 
>>> requires -fopenmp=libomp, which isn't in the set of standard "can we do 
>>> OpenMP" flags.) If people are supportive of it, I would suggest making it a 
>>> default variant.
>>>
>>> Note that -I/opt/local/include and -L/opt/local/lib (assuming standard 
>>> MacPorts install location) are required with -fopenmp for things to work 
>>> and not complain about missing omp.h or -lomp.
>>>
>>> If there is someone more familiar with clang/llvm building (of the tools 
>>> themselves), it might be interesting to consider baking in those -I/-L 
>>> flags (or move the libomp i

svn commit access down again this morning

[David Evans]

Ryan --

Authenication is failing on svn commits for me again this morning.  I see 
there's been some attempt to restart the
Mavericks buildbot (unsuccessfully as yet).  Perhaps this is related.

I did a forced rebuild on Mountain Lion of the build that failed with svn 
problems yesterday.  It got a good svn update
and is currently working through its backlog.  If the svn problem is not fixed 
it will fail again after this build.

Taking the rest of the day off.

Dave
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: llvm-3.7 release and OpenMP

[Lawrence Velázquez]

On Sep 3, 2015, at 12:21 PM, Jack Howarth  wrote:

> You really will want to rewrite the llvm37 Portfile to use a cmake
> build. The openmp 3.7 can be built in-tree using cmake (with the
> sources placed at projects/openmp. Also the default for -fopenmp is
> still left as -fopenmp=libgomp in 3.7.0 but this can be changed
> with...

I'm not sure how I feel about using internal libraries, but I'll defer to 
Jeremy on this for now, as I'm currently seeking new employment and don't have 
time to work on MacPorts.

> ps Note that the perl-based Makefile build is no longer functional in
> 3.7.0 and is in the process of being completely removed for the 3.8.0
> release.

This is unfortunate for us, as using CMake will expand the dependency tree 
significantly, but I guess it can't be helped.

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: llvm-3.7 release and OpenMP

[Jack Howarth]

   You really will want to rewrite the llvm37 Portfile to use a cmake
build. The openmp 3.7 can be built in-tree using cmake (with the
sources placed at projects/openmp. Also the default for -fopenmp is
still left as -fopenmp=libgomp in 3.7.0 but this can be changed
with...

--- cfe-3.7.0.src/CMakeLists.txt.orig 2015-09-02 12:21:32.0 -0400
+++ cfe-3.7.0.src/CMakeLists.txt 2015-09-02 12:21:51.0 -0400
@@ -182,7 +182,7 @@
 set(DEFAULT_SYSROOT "" CACHE PATH
   "Default  to all compiler invocations for --sysroot=." )

-set(CLANG_DEFAULT_OPENMP_RUNTIME "libgomp" CACHE STRING
+set(CLANG_DEFAULT_OPENMP_RUNTIME "libomp" CACHE STRING
   "Default OpenMP runtime used by -fopenmp.")

 set(CLANG_VENDOR "" CACHE STRING

In fink, we set the explicit location of the buried libomp.dylib with...

--- cfe-3.7.0.src/lib/Driver/Tools.cpp.orig 2015-07-02
09:10:45.0 -0400
+++ cfe-3.7.0.src/lib/Driver/Tools.cpp  2015-07-03 21:43:42.0 -0400
@@ -6368,12 +6368,18 @@
options::OPT_fno_openmp, false)) {
 switch (getOpenMPRuntime(getToolChain(), Args)) {
 case OMPRT_OMP:
+  // Help clang find libomp.dylib
+  CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
   CmdArgs.push_back("-lomp");
   break;
 case OMPRT_GOMP:
+  // Help clang find libgomp.dylib
+  CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
   CmdArgs.push_back("-lgomp");
   break;
 case OMPRT_IOMP5:
+  // Help clang find libiomp5.dylib
+  CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
   CmdArgs.push_back("-liomp5");
   break;
 case OMPRT_Unknown:
@@ -8079,9 +8085,13 @@
 // Also link the particular OpenMP runtimes.
 switch (getOpenMPRuntime(ToolChain, Args)) {
 case OMPRT_OMP:
+ // Help clang find libomp.dylib
+ CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
   CmdArgs.push_back("-lomp");
   break;
 case OMPRT_GOMP:
+  // Help clang find libgomp.dylib
+  CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
   CmdArgs.push_back("-lgomp");

   // FIXME: Exclude this for platforms with libgomp that don't require
@@ -8089,6 +8099,8 @@
   CmdArgs.push_back("-lrt");
   break;
 case OMPRT_IOMP5:
+ // Help clang find libiomp5.dylib
+ CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
   CmdArgs.push_back("-liomp5");
   break;
 case OMPRT_Unknown:

to produce -L/sw/opt/llvm-3.7/lib on the linkage. Lastly, to build the
fat binary of libomp,
you need to pass cmake the flag -DLIBOMP_OSX_ARCHITECTURES="x86_64;i386".
   Jack
ps Note that the perl-based Makefile build is no longer functional in
3.7.0 and is in the process of being completely removed for the 3.8.0
release.

On Wed, Sep 2, 2015 at 9:59 PM, Jeremy Huddleston Sequoia
 wrote:
> Looks good to me.  Could you go ahead and push this to svn and also do 
> similar changes to the llvm-3.8 port for your openmp variant?
>
> Thanks,
> Jeremy
>
>> On Sep 2, 2015, at 15:34, Eric A. Borisch  wrote:
>>
>> Would have done a ticket, but with trac down
>>
>> Attached is a patch to update to the released llvm/clang-3.7 (this comments 
>> out the svn fetch code, removes the default +assertions, and adds checksums)
>>
>> As OpenMP is one of the much discussed items that llvm-3.7 brings to the 
>> table, I've added a +openmp variant to clang-3.7. This variants pulls in 
>> port:libomp and sets up clang such that "-fopenmp" will use it by default. 
>> This makes it much more likely for tools like autoconf to detect OpenMP 
>> support. (Without the variant, openmp support is still there, but it 
>> requires -fopenmp=libomp, which isn't in the set of standard "can we do 
>> OpenMP" flags.) If people are supportive of it, I would suggest making it a 
>> default variant.
>>
>> Note that -I/opt/local/include and -L/opt/local/lib (assuming standard 
>> MacPorts install location) are required with -fopenmp for things to work and 
>> not complain about missing omp.h or -lomp.
>>
>> If there is someone more familiar with clang/llvm building (of the tools 
>> themselves), it might be interesting to consider baking in those -I/-L flags 
>> (or move the libomp include/lib install directories so they only have omp.h 
>> and the libomp*.dylib files and using those) so -fopenmp would "just work." 
>> (Without the extra -I and -L)... Let me know if there is interest and I can 
>> rework the libomp port to support this.
>>
>> Thanks,
>>   - Eric
>> 
>
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev