Re: GSOC Ideas

[Mojca Miklavec]

Dear Marcus,

Thank you very much for the extensive list of fresh ideas :)

Just a few general explanations.

One general rule is that the suggested ideas should be something that
a mentor is able to implement himself in cca. 3 weeks. There might be
exceptions if you meet a really brilliant student (but the program
should also be able to work for students with basic programming
skills, who never worked on any big project before, who have never
seen or heard about Tcl before, who have never been using MacPorts
before). One of the super important goals of the program is to
introduce students to opensource and the project in particular, and
keep them engaged with the project. If the tasks are too challenging
for the students, they would likely drop out of the program and never
return. If we give them something that they can comprehend, they are
more likely to stick with the project.

I'm not too familiar with the base development, so in many cases I'm
unable to judge how much effort a certain task would be, I just wanted
to point out that we should not ask students to solve problems which
we are not able to solve ourselves. If the student gets stuck at some
point, we definitely need to be able to help them continue. I hope
that some others will provide further feedback about the suggested
projects for the base.

Also, in the past we were often stuck with the task being to complex,
then maybe implemented 60-80%, never rigorously tested, and
consequently never merged. This is bad and demotivating for both the
student and the project. I would say that ideally the first official
merge of the student's code should not be later than after 4 weeks, so
that it can get proper testing etc.

On Thu, 7 Feb 2019 at 14:12, Marcus Calhoun-Lopez wrote:
>
> [1] https://trac.macports.org/wiki/SummerOfCode#Projects
>
>  1. Update Orphaned Ports
>  I originally became interested in MacPorts development because I wanted 
> to install certain software, and the MacPorts version was (slightly) out of 
> date.

Same for me. Maybe we should stress that out more clearly on the website.

>  Fixing and/or updating ports is an excellent introduction to the 
> MacPorts systems (phases, variants, PortGroups, etc.).
>  It forces you to read the documentation (but only as an absolute last 
> resort) and examine commit histories.
>  This would not be the entire GSOC project, but it could be used as part 
> of the application process and/or a supplement to the main project.

Agreed. Actually, I would list this under "ideas for ports" section.
For some super complex software, or for stuff like "setting up the
whole ecosystem to allow reasonable packaging of npm or ruby packages"
or some other less trivial piece of software that could be a full-time
work for the summer.

>  2. Tweak qt5 PG
>  Currently, the qt5 PG defines three procedures to declare dependencies 
> on Qt components
>  
> (https://github.com/macports/macports-ports/blob/000ec3f12e02aa6c3159bd1608cd8607eb9e18f0/_resources/port1.0/group/qt5-1.0.tcl#L572).
>  These should almost certainly be `options`.

I agree that there's a lot in Qt5 that could be done, and it could
certainly fill the whole summer. Or KDE.

>  3. Make blacklisting MacPorts compilers easier.
>  Currently, the compiler_blacklist_versions PG makes blacklisting ranges 
> of compilers very easy, but it only works for Xcode compilers.
>  It would be nice, for example, to be able to have something like 
> `compiler.blacklist-append {macports-clang < 6.0}`.
>  See https://trac.macports.org/ticket/56093.

Agreed. Maybe not enough work for the full summer(?), but it could be
one part of the task.

>  4. Add support for x86_64h architecture.
>  x86_64h is a lot like  x86_64, except it allows compiler to take 
> advantage of the Haswell microarchitecture.
>  Unlike other architectures in MacPorts, x86_64h and x86_64 libraries can 
> be linked together.
>  As a side note, GCC does not support `-arch x86_64h`, but Xcode and 
> MacPort Clang do.
>  See https://github.com/openssl/openssl/pull/6497 for a discussion on why 
> OpenSSL did NOT want to add support for x86_64h.

This is completely out of my own expertise, so I cannot comment about it.
(I've never seen anyone explicitly requesting this, but I also have
absolutely no idea how much performance improvement this could bring.)

>  5. Allow for multiple runs of each phase.
>  There are times when it is convenient to run configure/build/destroot 
> more than once.
>  For example:
>  *) cargo depends on the port cargo-stage1, whose only purpose is to help 
> build cargo.
>  Instead, one could run configure/build and use the resulting binary 
> without installing another port.
>  *) fluidsynth depends on a subproject, which has no use beyond aiding 
> the build process.
>  The subproject does not inherit the MacPorts settings.
>  It would be nice to configure/build the subproject prop

OSX 10.6 clang / llvm circular dependency

[Michael Dickens]

It looks like on OSX 10.6 (and, thus possibly elsewhere) that llvm-7.0 and 
clang-7.0 create a circular dependency ... see the attached info. Not sure how 
to work around this, but it is quite a PITA to do the equivalent of "sudo port 
upgrade outdated" manually port by port ... Hoping someone can either fix this 
issue or tell me how to work around it so that I can make faster progress ... 
thx! - MLD

$ uname -a
Darwin mbp13-10-6.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 
16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386

$ port info clang-7.0 llvm-7.0
clang-7.0 @7.0.1 (lang)
Variants: [+]analyzer, assertions, debug, [+]emulated_tls,
  [+]libstdcxx, universal

Description:  Clang is an LLVM native C/C++/Objective-C compiler, which
  aims to deliver amazingly fast compiles (e.g. about 3x
  faster than GCC when compiling Objective-C code in a debug
  configuration), extremely useful error and warning
  messages and to provide a platform for building great
  source level tools. The included Clang Static Analyzer is
  a tool that automatically finds bugs in your code, and is
  a great example of the sort of tool that can be built
  using the Clang frontend as a library to parse C/C++ code.
Homepage: https://clang.llvm.org/

Extract Dependencies: xz
Build Dependencies:   cmake, cctools, cctools, clang-7.0
Library Dependencies: libxml2, libomp, llvm-7.0, python27, libedit, libffi,
  ncurses, zlib, libcxx
Runtime Dependencies: clang_select, ld64, cctools, perl5
Platforms:darwin
License:  NCSA
Maintainers:  Email: jerem...@macports.org, GitHub: jeremyhu
  Email: lar...@macports.org, GitHub: larryv
--
llvm-7.0 @7.0.1 (lang)
Sub-ports:clang-7.0, lldb-7.0
Variants: assertions, debug, [+]emulated_tls, ocaml, polly,
  universal

Description:  The LLVM Core libraries provide a modern source- and
  target-independent optimizer, along with code generation
  support for many popular CPUs (as well as some less common
  ones!) These libraries are built around a well specified
  code representation known as the LLVM intermediate
  representation ("LLVM IR").
Homepage: https://llvm.org/

Extract Dependencies: xz
Build Dependencies:   cmake, cctools, clang-7.0
Library Dependencies: libedit, libffi, ncurses, xar, zlib, libcxx
Runtime Dependencies: perl5, llvm_select
Platforms:darwin
License:  NCSA
Maintainers:  Email: jerem...@macports.org, GitHub: jeremyhu
  Email: lar...@macports.org, GitHub: larryv

Currently recommended Python version?

[Craig Treleaven]

I was about to update one of my ports, libcec, which currently depends on 
python34.  I see that python37 was added to MacPorts in the middle of 2018.  I 
don’t even know how libcec actually uses python.  I can’t see anything 
documented for the package that specifies or recommends a particular version.

Which version of python 3 should I use?

Craig

Re: Currently recommended Python version?

[mf2k]

Hi Craig,


> On Feb 8, 2019, at 9:17 AM, Craig Treleaven  wrote:
> 
> I was about to update one of my ports, libcec, which currently depends on 
> python34.  I see that python37 was added to MacPorts in the middle of 2018.  
> I don’t even know how libcec actually uses python.  I can’t see anything 
> documented for the package that specifies or recommends a particular version.
> 
> Which version of python 3 should I use?

Use python37 if it is supported by the project. Generally we should be using 
the latest supported version. 


Cheers!
Frank

Re: OSX 10.6 clang / llvm circular dependency

[Chris Jones]

Hi,

Clearly clang-7.0 and llvm-.7.0 cannot depend on clang-7.0 as a build 
dependency, that will never work.


I do not see this though myself, in my OSX10.6 VM. There they both 
depend on clang-3.7 to build. See below. This is fine.


You must have done something locally in your checkout to cause this 
circular dependency... ??


cheers Chris

MacVM106 ~/Projects/MacPorts/legacy-support >  port info clang-7.0 llvm-7.0
clang-7.0 @7.0.1 (lang)
Variants: [+]analyzer, assertions, debug, [+]emulated_tls, 
[+]libstdcxx, universal


Description:  Clang is an LLVM native C/C++/Objective-C 
compiler, which aims to deliver amazingly fast compiles (e.g. about 3x 
faster than GCC when compiling
  Objective-C code in a debug configuration), 
extremely useful error and warning messages and to provide a platform 
for building great source level
  tools. The included Clang Static Analyzer is a 
tool that automatically finds bugs in your code, and is a great example 
of the sort of tool that can
  be built using the Clang frontend as a library to 
parse C/C++ code.

Homepage: https://clang.llvm.org/

Extract Dependencies: xz
Build Dependencies:   cmake, cctools, cctools, clang-3.7
Library Dependencies: libxml2, libomp, llvm-7.0, python27, libedit, 
libffi, ncurses, zlib, libcxx

Runtime Dependencies: clang_select, ld64, cctools, perl5
Platforms:darwin
License:  NCSA
Maintainers:  Email: jerem...@macports.org, GitHub: jeremyhu
  Email: lar...@macports.org, GitHub: larryv
--
llvm-7.0 @7.0.1 (lang)
Sub-ports:clang-7.0, lldb-7.0
Variants: assertions, debug, [+]emulated_tls, ocaml, polly, 
universal


Description:  The LLVM Core libraries provide a modern source- 
and target-independent optimizer, along with code generation support for 
many popular CPUs (as well
  as some less common ones!) These libraries are 
built around a well specified code representation known as the LLVM 
intermediate representation ("LLVM

  IR").
Homepage: https://llvm.org/

Extract Dependencies: xz
Build Dependencies:   cmake, cctools, clang-3.7
Library Dependencies: libedit, libffi, ncurses, xar, zlib, libcxx
Runtime Dependencies: perl5, llvm_select
Platforms:darwin
License:  NCSA
Maintainers:  Email: jerem...@macports.org, GitHub: jeremyhu
  Email: lar...@macports.org, GitHub: larryv


On 08/02/2019 3:59 pm, Michael Dickens wrote:

It looks like on OSX 10.6 (and, thus possibly elsewhere) that llvm-7.0 and clang-7.0 
create a circular dependency ... see the attached info. Not sure how to work around this, 
but it is quite a PITA to do the equivalent of "sudo port upgrade outdated" 
manually port by port ... Hoping someone can either fix this issue or tell me how to work 
around it so that I can make faster progress ... thx! - MLD

$ uname -a
Darwin mbp13-10-6.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 
16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386

$ port info clang-7.0 llvm-7.0
clang-7.0 @7.0.1 (lang)
Variants: [+]analyzer, assertions, debug, [+]emulated_tls,
   [+]libstdcxx, universal

Description:  Clang is an LLVM native C/C++/Objective-C compiler, which
   aims to deliver amazingly fast compiles (e.g. about 3x
   faster than GCC when compiling Objective-C code in a 
debug
   configuration), extremely useful error and warning
   messages and to provide a platform for building great
   source level tools. The included Clang Static Analyzer is
   a tool that automatically finds bugs in your code, and is
   a great example of the sort of tool that can be built
   using the Clang frontend as a library to parse C/C++ 
code.
Homepage: https://clang.llvm.org/

Extract Dependencies: xz
Build Dependencies:   cmake, cctools, cctools, clang-7.0
Library Dependencies: libxml2, libomp, llvm-7.0, python27, libedit, libffi,
   ncurses, zlib, libcxx
Runtime Dependencies: clang_select, ld64, cctools, perl5
Platforms:darwin
License:  NCSA
Maintainers:  Email: jerem...@macports.org, GitHub: jeremyhu
   Email: lar...@macports.org, GitHub: larryv
--
llvm-7.0 @7.0.1 (lang)
Sub-ports:clang-7.0, lldb-7.0
Variants: assertions, debug, [+]emulated_tls, ocaml, polly,
   universal

Description:  The LLVM Core libraries provide a modern source- and
   target-independent optimizer, along with code generation
   support for many popular CPUs (as well as some less 
common
   ones!) These li

Re: OSX 10.6 clang / llvm circular dependency

[Jeremy Lavergne]

I ran into a similar situation last week trying to do the clang-5.0 
builds recommended under the smtube thread.


Perhaps something similar is occurring here?


On 2/8/19 11:40 AM, Chris Jones wrote:

Hi,

Clearly clang-7.0 and llvm-.7.0 cannot depend on clang-7.0 as a build 
dependency, that will never work.


I do not see this though myself, in my OSX10.6 VM. There they both 
depend on clang-3.7 to build. See below. This is fine.


You must have done something locally in your checkout to cause this 
circular dependency... ??


cheers Chris

Re: OSX 10.6 clang / llvm circular dependency

[Michael Dickens]

I'm trying rebuilding the PortIndex ... but, otherwise no the port tree is at 
the current GIT master and clean. I'm investigating ... - MLD

On Fri, Feb 8, 2019, at 11:40 AM, Chris Jones wrote:
> Hi,
> 
> Clearly clang-7.0 and llvm-.7.0 cannot depend on clang-7.0 as a build 
> dependency, that will never work.
> 
> I do not see this though myself, in my OSX10.6 VM. There they both 
> depend on clang-3.7 to build. See below. This is fine.
> 
> You must have done something locally in your checkout to cause this 
> circular dependency... ??
> 
> cheers Chris
> 
> MacVM106 ~/Projects/MacPorts/legacy-support >  port info clang-7.0 llvm-7.0
> clang-7.0 @7.0.1 (lang)
> Variants: [+]analyzer, assertions, debug, [+]emulated_tls, 
> [+]libstdcxx, universal
> 
> Description:  Clang is an LLVM native C/C++/Objective-C 
> compiler, which aims to deliver amazingly fast compiles (e.g. about 3x 
> faster than GCC when compiling
>Objective-C code in a debug configuration), 
> extremely useful error and warning messages and to provide a platform 
> for building great source level
>tools. The included Clang Static Analyzer is a 
> tool that automatically finds bugs in your code, and is a great example 
> of the sort of tool that can
>be built using the Clang frontend as a library to 
> parse C/C++ code.
> Homepage: https://clang.llvm.org/
> 
> Extract Dependencies: xz
> Build Dependencies:   cmake, cctools, cctools, clang-3.7
> Library Dependencies: libxml2, libomp, llvm-7.0, python27, libedit, 
> libffi, ncurses, zlib, libcxx
> Runtime Dependencies: clang_select, ld64, cctools, perl5
> Platforms:darwin
> License:  NCSA
> Maintainers:  Email: jerem...@macports.org, GitHub: jeremyhu
>Email: lar...@macports.org, GitHub: larryv
> --
> llvm-7.0 @7.0.1 (lang)
> Sub-ports:clang-7.0, lldb-7.0
> Variants: assertions, debug, [+]emulated_tls, ocaml, polly, 
> universal
> 
> Description:  The LLVM Core libraries provide a modern source- 
> and target-independent optimizer, along with code generation support for 
> many popular CPUs (as well
>as some less common ones!) These libraries are 
> built around a well specified code representation known as the LLVM 
> intermediate representation ("LLVM
>IR").
> Homepage: https://llvm.org/
> 
> Extract Dependencies: xz
> Build Dependencies:   cmake, cctools, clang-3.7
> Library Dependencies: libedit, libffi, ncurses, xar, zlib, libcxx
> Runtime Dependencies: perl5, llvm_select
> Platforms:darwin
> License:  NCSA
> Maintainers:  Email: jerem...@macports.org, GitHub: jeremyhu
>Email: lar...@macports.org, GitHub: larryv

Re: OSX 10.6 clang / llvm circular dependency

[Chris Jones]

Hi,

I was more referring to your macports configuration than the ports tree itself. 
Are you sure you aren’t overriding the compiler configuration from what would 
otherwise be the default setting ? That would be my best guess.

Chris

> On 8 Feb 2019, at 6:23 pm, Michael Dickens  wrote:
> 
> I'm trying rebuilding the PortIndex ... but, otherwise no the port tree is at 
> the current GIT master and clean. I'm investigating ... - MLD
> 
>> On Fri, Feb 8, 2019, at 11:40 AM, Chris Jones wrote:
>> Hi,
>> 
>> Clearly clang-7.0 and llvm-.7.0 cannot depend on clang-7.0 as a build 
>> dependency, that will never work.
>> 
>> I do not see this though myself, in my OSX10.6 VM. There they both 
>> depend on clang-3.7 to build. See below. This is fine.
>> 
>> You must have done something locally in your checkout to cause this 
>> circular dependency... ??
>> 
>> cheers Chris
>> 
>> MacVM106 ~/Projects/MacPorts/legacy-support >  port info clang-7.0 llvm-7.0
>> clang-7.0 @7.0.1 (lang)
>> Variants: [+]analyzer, assertions, debug, [+]emulated_tls, 
>> [+]libstdcxx, universal
>> 
>> Description:  Clang is an LLVM native C/C++/Objective-C 
>> compiler, which aims to deliver amazingly fast compiles (e.g. about 3x 
>> faster than GCC when compiling
>>   Objective-C code in a debug configuration), 
>> extremely useful error and warning messages and to provide a platform 
>> for building great source level
>>   tools. The included Clang Static Analyzer is a 
>> tool that automatically finds bugs in your code, and is a great example 
>> of the sort of tool that can
>>   be built using the Clang frontend as a library to 
>> parse C/C++ code.
>> Homepage: https://clang.llvm.org/
>> 
>> Extract Dependencies: xz
>> Build Dependencies:   cmake, cctools, cctools, clang-3.7
>> Library Dependencies: libxml2, libomp, llvm-7.0, python27, libedit, 
>> libffi, ncurses, zlib, libcxx
>> Runtime Dependencies: clang_select, ld64, cctools, perl5
>> Platforms:darwin
>> License:  NCSA
>> Maintainers:  Email: jerem...@macports.org, GitHub: jeremyhu
>>   Email: lar...@macports.org, GitHub: larryv
>> --
>> llvm-7.0 @7.0.1 (lang)
>> Sub-ports:clang-7.0, lldb-7.0
>> Variants: assertions, debug, [+]emulated_tls, ocaml, polly, 
>> universal
>> 
>> Description:  The LLVM Core libraries provide a modern source- 
>> and target-independent optimizer, along with code generation support for 
>> many popular CPUs (as well
>>   as some less common ones!) These libraries are 
>> built around a well specified code representation known as the LLVM 
>> intermediate representation ("LLVM
>>   IR").
>> Homepage: https://llvm.org/
>> 
>> Extract Dependencies: xz
>> Build Dependencies:   cmake, cctools, clang-3.7
>> Library Dependencies: libedit, libffi, ncurses, xar, zlib, libcxx
>> Runtime Dependencies: perl5, llvm_select
>> Platforms:darwin
>> License:  NCSA
>> Maintainers:  Email: jerem...@macports.org, GitHub: jeremyhu
>>   Email: lar...@macports.org, GitHub: larryv

Re: OSX 10.6 clang / llvm circular dependency

[Eric A. Borisch]

Try updating and going again; 7.0 needed to be added to the
blacklist-if-not-installed loop in libomp. Not sure if this is your issue,
but can't hurt.


On Fri, Feb 8, 2019 at 12:52 PM Chris Jones 
wrote:

> Hi,
>
> I was more referring to your macports configuration than the ports tree
> itself. Are you sure you aren’t overriding the compiler configuration from
> what would otherwise be the default setting ? That would be my best guess.
>
> Chris
>
> > On 8 Feb 2019, at 6:23 pm, Michael Dickens 
> wrote:
> >
> > I'm trying rebuilding the PortIndex ... but, otherwise no the port tree
> is at the current GIT master and clean. I'm investigating ... - MLD
> >
> >> On Fri, Feb 8, 2019, at 11:40 AM, Chris Jones wrote:
> >> Hi,
> >>
> >> Clearly clang-7.0 and llvm-.7.0 cannot depend on clang-7.0 as a build
> >> dependency, that will never work.
> >>
> >> I do not see this though myself, in my OSX10.6 VM. There they both
> >> depend on clang-3.7 to build. See below. This is fine.
> >>
> >> You must have done something locally in your checkout to cause this
> >> circular dependency... ??
> >>
> >> cheers Chris
> >>
> >> MacVM106 ~/Projects/MacPorts/legacy-support >  port info clang-7.0
> llvm-7.0
> >> clang-7.0 @7.0.1 (lang)
> >> Variants: [+]analyzer, assertions, debug, [+]emulated_tls,
> >> [+]libstdcxx, universal
> >>
> >> Description:  Clang is an LLVM native C/C++/Objective-C
> >> compiler, which aims to deliver amazingly fast compiles (e.g. about 3x
> >> faster than GCC when compiling
> >>   Objective-C code in a debug configuration),
> >> extremely useful error and warning messages and to provide a platform
> >> for building great source level
> >>   tools. The included Clang Static Analyzer is a
> >> tool that automatically finds bugs in your code, and is a great example
> >> of the sort of tool that can
> >>   be built using the Clang frontend as a library to
> >> parse C/C++ code.
> >> Homepage: https://clang.llvm.org/
> >>
> >> Extract Dependencies: xz
> >> Build Dependencies:   cmake, cctools, cctools, clang-3.7
> >> Library Dependencies: libxml2, libomp, llvm-7.0, python27, libedit,
> >> libffi, ncurses, zlib, libcxx
> >> Runtime Dependencies: clang_select, ld64, cctools, perl5
> >> Platforms:darwin
> >> License:  NCSA
> >> Maintainers:  Email: jerem...@macports.org, GitHub: jeremyhu
> >>   Email: lar...@macports.org, GitHub: larryv
> >> --
> >> llvm-7.0 @7.0.1 (lang)
> >> Sub-ports:clang-7.0, lldb-7.0
> >> Variants: assertions, debug, [+]emulated_tls, ocaml, polly,
> >> universal
> >>
> >> Description:  The LLVM Core libraries provide a modern source-
> >> and target-independent optimizer, along with code generation support
> for
> >> many popular CPUs (as well
> >>   as some less common ones!) These libraries are
> >> built around a well specified code representation known as the LLVM
> >> intermediate representation ("LLVM
> >>   IR").
> >> Homepage: https://llvm.org/
> >>
> >> Extract Dependencies: xz
> >> Build Dependencies:   cmake, cctools, clang-3.7
> >> Library Dependencies: libedit, libffi, ncurses, xar, zlib, libcxx
> >> Runtime Dependencies: perl5, llvm_select
> >> Platforms:darwin
> >> License:  NCSA
> >> Maintainers:  Email: jerem...@macports.org, GitHub: jeremyhu
> >>   Email: lar...@macports.org, GitHub: larryv
>
>

Re: OSX 10.6 clang / llvm circular dependency

[Michael Dickens]

Updated; rebuilt the PortIndex. No different. I find the following very
curious. "cmake" depends on itself circularly, which just can't be good;
and, the internal cmake dependency has somewhat different dependencies
compared with the outer one. It also has direct dependencies on clang-
7.0 and llvm-7.0, which doesn't seem correct to me based on the
Portfile. H ...{{{
$ port rdeps cmake
The following ports are dependencies of cmake @3.13.4_0:
  clang-7.0
xz
  libiconv
gperf
  gettext
ncurses
cmake
  curl
pkgconfig
libidn2
  autoconf
  automake
  libtool
xattr
  unzip
  libunistring
perl5
  perl5.26
db48
gdbm
  readline
texinfo
  help2man
perl5.28
p5.28-locale-gettext
libpsl
  python27
bzip2
expat
libedit
libffi
openssl
  zlib
sqlite3
python_select
python2_select
  glib2
libxml2
  icu
pcre
curl-ca-bundle
  libarchive
lzo2
lz4
zstd
  libuv
legacy-support
  libcxx
clang-6.0
  cctools
libunwind-headers
llvm-3.4
  llvm_select
  libomp
  llvm-6.0
xar
  clang_select
  ld64
ld64-127
  libmacho-headers
llvm-7.0
}}}

Re: OSX 10.6 clang / llvm circular dependency

[Christopher Jones]

> On 8 Feb 2019, at 7:43 pm, Michael Dickens  wrote:
> 
> Updated; rebuilt the PortIndex. No different. I find the following very 
> curious. "cmake" depends on itself circularly, which just can't be good; and, 
> the internal cmake dependency has somewhat different dependencies compared 
> with the outer one. It also has direct dependencies on clang-7.0 and 
> llvm-7.0, which doesn't seem correct to me based on the Portfile. H …

Thats not what strikes me. Its the fact this also depends on clang-7.0.

I really suspect something in your setup is forcing the use of this compiler on 
all ports…

> {{{
> $ port rdeps cmake
> The following ports are dependencies of cmake @3.13.4_0:
>   clang-7.0
> xz
>   libiconv
> gperf
>   gettext
> ncurses
> cmake
>   curl
> pkgconfig
> libidn2
>   autoconf
>   automake
>   libtool
> xattr
>   unzip
>   libunistring
> perl5
>   perl5.26
> db48
> gdbm
>   readline
> texinfo
>   help2man
> perl5.28
> p5.28-locale-gettext
> libpsl
>   python27
> bzip2
> expat
> libedit
> libffi
> openssl
>   zlib
> sqlite3
> python_select
> python2_select
>   glib2
> libxml2
>   icu
> pcre
> curl-ca-bundle
>   libarchive
> lzo2
> lz4
> zstd
>   libuv
> legacy-support
>   libcxx
> clang-6.0
>   cctools
> libunwind-headers
> llvm-3.4
>   llvm_select
>   libomp
>   llvm-6.0
> xar
>   clang_select
>   ld64
> ld64-127
>   libmacho-headers
> llvm-7.0
> }}}



smime.p7s
Description: S/MIME cryptographic signature

Re: OSX 10.6 clang / llvm circular dependency

[Michael Dickens]

On Fri, Feb 8, 2019, at 3:02 PM, Christopher Jones wrote:
>> On 8 Feb 2019, at 7:43 pm, Michael Dickens
>>  wrote:>> 
>> Updated; rebuilt the PortIndex. No different. I find the following
>> very curious. "cmake" depends on itself circularly, which just can't
>> be good; and, the internal cmake dependency has somewhat different
>> dependencies compared with the outer one. It also has direct
>> dependencies on clang-7.0 and llvm-7.0, which doesn't seem correct to
>> me based on the Portfile. H …> 
> Thats not what strikes me. Its the fact this also depends on
> clang-7.0.> 
> I really suspect something in your setup is forcing the use of this
> compiler on all ports…
clang-7.0 is not required on all ports. I've updated those ports where
this circular dependency doesn't exist.
I just checked all of the conf files in PREFIX/etc/macports & updated
them to the latest with my minimal tweaks (applications_dir and sources
location). Otherwise my MP install is "stock" and "normal" and
completely update to date (just reinstalled today; "base" is stock
excepting the version found in config/macports_version).
A few more data points that might be useful:

(1) On 10.6, if I do "sudo port rev", when I tell it to proceed, it
comes back with the following:{{{
Continue? [Y/n]:
Warning: No port clang-7.0 found in the index.
Warning: No port libomp found in the index.
Warning: No port llvm-7.0 found in the index.
Warning: No port libcxx found in the index.
Warning: No port clang_select found in the index.
Warning: No port ld64 found in the index.
--->  Computing dependencies for clang-7.0Error: Problem while
installing clang-7.0}}}
... but, each of these ports is in the PortIndex .. I assume that's what
"index" means here. So, what does "port" think it's doing?
(2) On 10.10 on a different computer / MP install, I'm updating some
ports (e.g., uhd-devel) and see that they are dependent on MP clang-
7.0, which makes no sense ... uhd-devel just requires a c++11
compliant compiler. No reason why MP clang-7.0 ... could be an older
version. Luckily on 10.10 there is no circular dependency, so
everything installs; that and I generally try to have all of the
major compilers installed for testing purposes anyway ... so, good
to get clang 7.0 installed anyway.
(3) clang-7.0 depends on cmake, which requires c++11 for building. Maybe
the circular dependency is coming through cmake's c++11, which
somehow for some older OSX requires clang-7.0 ... here's an
interesting point:
In the cmake Portfile, if I insert this line:
{{{
ui_msg "configure.compiler is '${configure.compiler}'"
}}}
both before and after the line:
{{{
PortGroup cxx11 1.1
}}}
then before I see the compiler is 'gcc-4.2', while after it is 'macports-clang-
7.0' ... so, somehow the cxx11 1.1 PG is picking the incorrect compiler!
H ... will continue investigating! - MLD

Re: OSX 10.6 clang / llvm circular dependency

[Michael Dickens]

OK some more sleuthing turns up that the issue was not the cxx11 PG, but
rather this line in the cmake Portfile:{{{
configure.cxx_stdlib libc++
}}}
before this line, the compiler is 'gcc-4.2', while after it is
'macports-clang-7.0' ... I'll keep poking, but I'm about done
with the rabbit hole ... - MLD

Re: OSX 10.6 clang / llvm circular dependency

[Chris Jones]

> On 8 Feb 2019, at 8:55 pm, Michael Dickens  wrote:
> 
> OK some more sleuthing turns up that the issue was not the cxx11 PG, but 
> rather this line in the cmake Portfile:
> {{{
> configure.cxx_stdlib libc++
> }}}
> before this line, the compiler is 'gcc-4.2', while after it is 
> 'macports-clang-7.0' ... I'll keep poking, but I'm about done with the rabbit 
> hole ... - MLD

If i am not mistaken that line has been there since aug 2017, and only active 
with 10.5 or older. 

https://github.com/macports/macports-ports/blob/master/devel/cmake/Portfile#L13

Does what you have differ from what is in master ?

Re: OSX 10.6 clang / llvm circular dependency

[Michael Dickens]

My ports tree is up to date with no modifications, according to "git".

Note that the 'if' clause that this line is in is -not- of the
arguments, so it is valid for OSX with uname major >= 10 -- which
includes OSX 10.6 (== 10).
On Fri, Feb 8, 2019, at 4:01 PM, Chris Jones wrote:
> On 8 Feb 2019, at 8:55 pm, Michael Dickens
>  wrote:>> OK some more sleuthing turns up that the 
> issue was not the cxx11 PG,
>> but rather this line in the cmake Portfile:>> {{{
>> configure.cxx_stdlib libc++
>> }}}
>> before this line, the compiler is 'gcc-4.2', while after it is 
>> 'macports-clang-
>> 7.0' ... I'll keep poking, but I'm about done with the rabbit hole
>> ... - MLD> 
> If i am not mistaken that line has been there since aug 2017, and only
> active with 10.5 or older.> 
> https://github.com/macports/macports-ports/blob/master/devel/cmake/Portfile#L13>
>  
> Does what you have differ from what is in master ?

Re: OSX 10.6 clang / llvm circular dependency

[Michael Dickens]

Adding in some debug printouts inside portconfigure.tcl, I think what's
happening is that when "libc++" is specified, somewhere inside
portconfigure.tcl the possible compilers to used gets pared down. Since
I'm not specifying one by default, and there is no blacklist or
whitelist, the fallback list is used. The first "compiler.fallback" on
OSX 10.6 that meets the requirement to support "libc++" is "macports-clang-
7.0". Not sure if this help anyone, but it explains why the dependency
on clang-7.0 for cmake at least. - MLD

Re: OSX 10.6 clang / llvm circular dependency

[Christopher Jones]

> On 8 Feb 2019, at 9:32 pm, Michael Dickens  wrote:
> 
> Adding in some debug printouts inside portconfigure.tcl, I think what's 
> happening is that when "libc++" is specified, somewhere inside 
> portconfigure.tcl the possible compilers to used gets pared down. Since I'm 
> not specifying one by default, and there is no blacklist or whitelist, the 
> fallback list is used. The first "compiler.fallback" on OSX 10.6 that meets 
> the requirement to support "libc++" is "macports-clang-7.0". Not sure if this 
> help anyone, but it explains why the dependency on clang-7.0 for cmake at 
> least. - MLD

OK, but why then do you see this on OSX 10.6, but I don’t (i.e. see my first 
mail, with the clang/llvm deps) ?

Something has to be different between the two, to get a different outcome.

Chris



smime.p7s
Description: S/MIME cryptographic signature

Re: OSX 10.6 clang / llvm circular dependency

[Joshua Root]

On 2019-2-9 08:39 , Christopher Jones wrote:
> 
> 
>> On 8 Feb 2019, at 9:32 pm, Michael Dickens > > wrote:
>>
>> Adding in some debug printouts inside portconfigure.tcl, I think
>> what's happening is that when "libc++" is specified, somewhere
>> inside portconfigure.tcl the possible compilers to used gets pared
>> down. Since I'm not specifying one by default, and there is no
>> blacklist or whitelist, the fallback list is used. The first
>> "compiler.fallback" on OSX 10.6 that meets the requirement to support
>> "libc++" is "macports-clang-7.0". Not sure if this help anyone, but it
>> explains why the dependency on clang-7.0 for cmake at least. - MLD
> 
> OK, but why then do you see this on OSX 10.6, but I don’t (i.e. see my
> first mail, with the clang/llvm deps) ?
> 
> Something has to be different between the two, to get a different outcome.

Current release of base vs master perhaps?

- Josh

Re: Load dynamic library for python library

[Casey Deccio]

> On Feb 7, 2019, at 8:05 PM, Joshua Root  > wrote:
> 
> On 2019-2-8 13:59 , Casey Deccio wrote:
>> 
>> 
>>> On Feb 7, 2019, at 7:03 PM, Joshua Root >> > wrote:
>>> 
>>> BTW Gmail decided my reply was spam; sending only to the list this time
>>> so Casey might actually see it...
>> 
>> Much appreciated :)
>> 
>>> On 2019-2-8 13:00 , Joshua Root wrote:
 
 Ctypes uses dlopen behind the scenes, and if you look at dlopen's man
 page, it only searches a small set of fallback paths when the full path
 to the library is not supplied, most of which are controlled by
 environment variables. So I would say that py-libnacl should be passing
 the full path to libnacl to ctypes.cdll.LoadLibrary.
>> 
>> Thanks for the feedback!  I figured it should have that path provided 
>> somehow.  So, should an issue/pull request be filed with the py-libnacl port 
>> then?  Where is the right place for the path to be provided?
> 
> The call is in libnacl/__init__.py. I'd patch in a placeholder and use
> reinplace to insert the value of $prefix.

Thanks!  So would it be better for the patch to try first the hard-coded 
location (i.e., hardcoded with ${prefix}) then via relative name/search or just 
the hardcoded?

That is,

$ git diff
diff --git a/libnacl/__init__.py b/libnacl/__init__.py
index 1b037ac..c2c321a 100644
--- a/libnacl/__init__.py
+++ b/libnacl/__init__.py
@@ -34,7 +34,7 @@ def _get_nacl():
 raise OSError(msg)
 elif sys.platform.startswith('darwin'):
 try:
-return ctypes.cdll.LoadLibrary('libsodium.dylib')
+return ctypes.cdll.LoadLibrary(os.path.join('@@PREFIX@@', 
'libsodium.dylib'))
 except OSError:
 pass
 try:

vs.

$ git diff
diff --git a/libnacl/__init__.py b/libnacl/__init__.py
index 1b037ac..648f885 100644
--- a/libnacl/__init__.py
+++ b/libnacl/__init__.py
@@ -37,6 +37,10 @@ def _get_nacl():
 return ctypes.cdll.LoadLibrary('libsodium.dylib')
 except OSError:
 pass
+try:
+return ctypes.cdll.LoadLibrary(os.path.join('@@PREFIX@@', 
'libsodium.dylib'))
+except OSError:
+pass
 try:
 libidx = __file__.find('lib')
 if libidx > 0:

Casey

Re: Load dynamic library for python library

[Joshua Root]

On 2019-2-9 09:20 , Casey Deccio wrote:
> 
>> On Feb 7, 2019, at 8:05 PM, Joshua Root > > wrote:
>>
>> The call is in libnacl/__init__.py. I'd patch in a placeholder and use
>> reinplace to insert the value of $prefix.
> 
> Thanks!  So would it be better for the patch to try first the hard-coded
> location (i.e., hardcoded with ${prefix}) then via relative name/search
> or just the hardcoded?

I already committed the change. No fallback because we only want to use
the MacPorts version of libsodium. There's a dependency on it, so if
it's missing something has gone very wrong.

- Josh

Re: Load dynamic library for python library

[Casey Deccio]

> On Feb 8, 2019, at 4:05 PM, Joshua Root  wrote:
> 
> 
> I already committed the change.

Whoops - I see that now.  Thanks!

> No fallback because we only want to use
> the MacPorts version of libsodium. There's a dependency on it, so if
> it's missing something has gone very wrong.

Indeed.

Thanks again,
Casey

Re: Load dynamic library for python library

[Casey Deccio]

> On Feb 8, 2019, at 4:05 PM, Joshua Root  wrote:
> 
> 
> I already committed the change.

Whoops - I see that now.  Thanks!

> No fallback because we only want to use
> the MacPorts version of libsodium. There's a dependency on it, so if
> it's missing something has gone very wrong.

Indeed.

Thanks again,
Casey

Re: OSX 10.6 clang / llvm circular dependency

[Chris Jones]

> On 8 Feb 2019, at 10:19 pm, Joshua Root  wrote:
> 
>> On 2019-2-9 08:39 , Christopher Jones wrote:
>> 
>> 
>>> On 8 Feb 2019, at 9:32 pm, Michael Dickens >> > wrote:
>>> 
>>> Adding in some debug printouts inside portconfigure.tcl, I think
>>> what's happening is that when "libc++" is specified, somewhere
>>> inside portconfigure.tcl the possible compilers to used gets pared
>>> down. Since I'm not specifying one by default, and there is no
>>> blacklist or whitelist, the fallback list is used. The first
>>> "compiler.fallback" on OSX 10.6 that meets the requirement to support
>>> "libc++" is "macports-clang-7.0". Not sure if this help anyone, but it
>>> explains why the dependency on clang-7.0 for cmake at least. - MLD
>> 
>> OK, but why then do you see this on OSX 10.6, but I don’t (i.e. see my
>> first mail, with the clang/llvm deps) ?
>> 
>> Something has to be different between the two, to get a different outcome.
> 
> Current release of base vs master perhaps?

Perhaps. I am running the latest release, not master.

> 
> - Josh