Help with Ticket #68015

[Marcus Calhoun-Lopez]

As part of its build process, Rust creates a program called
`bootstrap`, which reports a stack overflow on 10.9 and 10.10 (see
ticket #68015).

What I cannot figure out is the following.
If I take the `bootstrap` built on 10.8, then it works just fine on
10.8 and 10.11.
That same binary crashes on t0.9 and 10.10.
If I take the `bootstrap` built on 10.9, then it crashes on 10.9.
However, that same binary runs fine on 10.10.

Can anyone imagine a scenario where the same binary runs on 10.8 and
10.11 but crashes on 10.9 and 10.10?

Thanks,
Marcus

Create new version of legacy-support

[Marcus Calhoun-Lopez]

Are there any objections to creating version 1.3.0 of legacy-support?
legacy-support-devel seems to be working, and some of the features are
needed for the latest version of Rust.

Thanks,
Marcus

Location to store binaries

[Marcus Calhoun-Lopez]

As many of you know, the standard Rust compiler is self-hosting.
The upstream bootstrap compiler only works (unmodified) on 64-bit 10.9+.

There is an attempt to build a bootstrap compiler that runs on older
systems [1].
One stumbling block is where to build and store the bootstrap compilers.
I am afraid I know little about this.
Github packages, JFrog, other?
Does anyone have any suggestions?

Thanks,
Marcus

1) https://github.com/macports/macports-ports/pull/14277

Help with legacy-support

[Marcus Calhoun-Lopez]

Greetings.

I have been experimenting with Rust on older systems.
The first problem I have encountered is the missing symbol "__tlv_bootstrap."
Apparently, it was first introduced in 10.7
(https://github.com/rust-lang/rust/issues/10842).
Does anyone happen to know if this a candidate for inclusion in legacy-support?

Thanks,
Marcus

Help Understanding Code Signing

[Marcus Calhoun-Lopez]

I must admit that whan issues like code signing come up, I tend to
tune out, so please forgive me if this is well trodden territory.

While working on the netgen, I added the following code to get the
destroot phase working (where ${pdv} is 3.8, 3.9, etc.):
destroot.env-append
PYTHONPATH=${destroot}${prefix}/lib/python${pdv}/site-packages/ \

DYLD_LIBRARY_PATH=${destroot}${prefix}/lib

In the CMake file, PYTHONPATH is respected by execute_process [1], but
DYLD_LIBRARY_PATH is not.
>From what I can tell, this is an OS issue and not a cmake problem [2].
Apparently, the solution is to run codesign on cmake.
Is this at all feasible?
Is there another possible workaround anyone can think of?
I am afraid I know little to nothing about how codesign [3] works.

Thank you,
Marcus

[1] https://cmake.org/cmake/help/latest/command/execute_process.html
[2] https://gitlab.kitware.com/cmake/cmake/-/issues/20678
[3] 
https://developer.apple.com/library/archive/documentation/Security/Conceptual/CodeSigningGuide/Procedures/Procedures.html

Fortran changes in GCC 10

[Marcus Calhoun-Lopez]

By default, the about to be released GCC 10 is more strict about Fortran 
argument types [1].
Code that once only produced warnings now produce errors.
So far, I have run into this problem three times.
MPICH is aware of the issue but is unsure how they are going to proceed [2,3].
GetDP required a minor patch that has already be accepted upstream [4].
ScaLAPACK produced a deluge of error.
I submitted a bug report, but I have no desire to construct a patch [5].

As I recall from a summer working with legacy FORTRAN 77 code written by 
mathematicians, the priorities were roughly:
1. code produces output that looks good in a publication
2. code is fast
3. code produces correct results
4. …
42. code adheres to best programming practices

As such, I am sure that many Fortran based project will run into this issue.
Ideally, these kinds of things would be fixed upstream.
Until then, the workaround is to add `-fallow-argument-mismatch` to the 
gfortran compiler.
Unfortunately, the flag is not unrecognized by any GCC < 10 and hence produces 
an error.

We could design a separate PortGroup to address the problem, but it would have 
to be so tightly tied to the compilers PG that it made more sense to simply 
modify the compilers PG directly [6].
If anyone else runs into this problem and a patch is not feasible, 
`compilers.allow_arguments_mismatch yes` should hopefully fix the problem.

-Marcus

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556
[2] https://lists.mpich.org/pipermail/discuss/2020-January/005862.html
[3] https://github.com/pmodels/mpich/issues/4300
[4] https://gitlab.onelab.info/getdp/getdp/-/issues/61
[5] https://github.com/Reference-ScaLAPACK/scalapack/issues/21
[6] 
https://github.com/macports/macports-ports/commit/20b350bb5eb864e9323f2f79324a2f7f977942d1

Significant changes to mpich port

[Marcus Calhoun-Lopez]

There is a PR (#6899) that makes significant changes to the mpich port.
The most impactful change is probably the reworking of -devel ports to make 
them behave more like other -devel ports.
The PR has been open for over a week, but I would be happy to keep it open if 
anyone would like to comment (or object).

If the mpich changes are merged, I will make similar changes to openmpi.

-Marcus

https://github.com/macports/macports-ports/pull/6899

Re: Introduction for GSoC - Darsh

[Marcus Calhoun-Lopez]

Greetings Darsh,

We are glad to hear about your interest in the MacPorts project.

I am afraid I do not know much about the npm audit feature (or npm for that 
matter).
How do you propose to determine that a security vulnerability exists?
If a vulnerability is identified, what would your project propose to do about 
it?

As for helping with the build infrastructure, I am afraid others will have to 
chime in with suggestions.

-Marcus

> On Mar 13, 2020, at 11:28 AM, Darsh Patel  wrote:
> 
> Hello everyone! 
>I'm Darsh, I'm 19 and I'm a Computer science undergrad. I'll give a super 
> short introduction in the and talk about my ideas for MacPorts, 
> 
> I'm currently working part-time for a LegalTech Startup ( for free, no 
> obligations per se) as a DevOps and Backend Lead. I've been into tech since a 
> very young age, put on paper ( literally ) by this article in Times of India 
> about a smart home project I built when I was 14. 
> I'm primarily a backend developer, but I'm competent with the rest of the 
> stack too.  I also have a background in CyberSecurity ( I have a CEH 
> Certification too ). Here's my CV in case you want to know more
> 
> My Project idea for GSoC: I'd like to help implement vulnerability scanning 
> and audit for ports, Similar to npm's "audit" feature. I was also looking 
> into writing scripts to help current ports follow better security practices 
> and enforce them. 
> Also, is there a need/plan to change the build infrastructure? I'd love to 
> help with that in any way I can, helping with improving logging / more 
> efficient package builds, etc. 
> 
> I'm all ears for feedback and suggestions for my ideas, 
> 
> Super Excited, 
> Darsh 
> 
> 

Re: GSoC

[Marcus Calhoun-Lopez]

Greetings Vibhansh,

We are glad to hear about your interest in the MacPorts project.

A few questions.
Are you familiar with Tcl?
It is not mandatory, you can pick up what you need fairly quickly.
Are you familiar with MacPorts?
Again, it is not mandatory, it just helps to know how much vocabulary we can 
initially use.

I think the best advice I can give at this point is to develop a history of 
code, reliability, and working with other developers.
Some possible suggestions to get you started:

* You said you were invested in improving the Command Line Tool UX.
   Perhaps take *one* aspect of that and see if you (with help from other 
developers) can implement it.
   For example, just adding color (red for errors, yellow for warnings, etc.) 
might be a reasonable place to start.

*  Choose some outdated ports and try to update them [1].
   Running “port livecheck maintainer:nomaintainer” give a (very long) list of 
outdated unmaintained port.
   You could try to update a few of them.
   This would also get you a little more acquainted with Tcl if you are not 
already.

*  Choose some tickets [2] and try to fix them.
   Some tickets are open for a long time because they are difficult.
   However, some tickets are still open just because no-one has put any effort 
into fixing them.
   For example, “Base should know the installed version of the command line 
tools” [3] is fairly easy to fix.
   There is a PortGroup that already does much of the heavy lifting [4].
   I just have not gotten around to incorporating the PortGroup into the base 
code.

There are just a few possible options.
Feel free to contribute your own ideas.

-Marcus

[1] https://trac.macports.org/wiki/SummerOfCode#orphanports
[2] https://trac.macports.org/report/1?sort=created=0=1
[3] https://trac.macports.org/ticket/56318
[4] 
https://github.com/macports/macports-ports/blob/master/_resources/port1.0/group/cltversion-1.0.tcl

> On Mar 7, 2020, at 3:23 PM, Vibhansh Gupta  wrote:
> 
> Hi there !
> 
> I’m Vibhansh. A Tech Enthusiast who has become very interested, after reading 
> through the project description and requirements, to work towards to goal, 
> "Improving the Command Line Tool UX” (in GSoC 2020 for MacPorts and perhaps 
> even further down the road).
> 
> As for my experience and programming skills, I am glad to inform you that I 
> have been working thoroughly in Python for over 2 years now. I know that 
> there will be many candidates showing an interest to aim for improving the UX 
> but I would like to point out why I would be the better choice. Yes, it will 
> probably be true that I may not be the best programmer but why I’d be 
> specifically the best choice for this project can be explained in twofolds :
> 1. I am very fluent with understanding code. I pick up coding terms quicker 
> than most and can see the structure as well as the code to come to the 
> conclusion about what parts are relating to which feature. I think this will 
> help me identify the relevant parts for the UX editing.
> 2. In any project that I pursue, I give the utmost emphasis on creating the 
> best User Experience or if it is a Web-based project, I give User Interface 
> the most priority. It’s an obsession, really. With that in mind, I would like 
> to point out that I will be more than happy to undertake any sort of User 
> Experience improvement project for the MacPorts Community.
> 
> A few tips of guidance would be deeply appreciated as I try to step forth and 
> (hopefully) contribute toward’s your goal.
> 
> Sincerely,
> Vibhansh.

Re: GSOC 20

[Marcus Calhoun-Lopez]

Greetings Pavitra,

The MacPorts GSoC wiki page is good place to start 
(https://trac.macports.org/wiki/SummerOfCode).

-Marcus

> On Feb 7, 2020, at 11:46 AM, Pavitra Behre  wrote:
> 
> Hello,
> I'm Pavitra, Pre-final year student of B.Tech - Computer Science & 
> Engineering.
> I'm very much interested in contributing to MacPorts under GSOC 20.
> Kindly guide me on the How-Tos.
> A little bit about myself: I've been coding for approximately 7 years now and 
> my primary domain used to be web development and backend development. But for 
> past year or two, I'e switched to python and MacOs. Been using UNIX based 
> systems for more than half a decade. 
> Hoping to hear soon,
> Thank you,
> Pavitra Behre

Re: Opportunity to Contribute to MacPorts

[Marcus Calhoun-Lopez]

With Tanvi’s permission, I am responding to her email on the MacPorts mailing 
list so that others can join the conversation.

Welcome.

There are several ways to start to contribute to the MacPorts project.
It might help if you talked a little about your background.
Have you read the the MacPorts Project’s page for GSoC [1]?
The “Skills” section of you CV should allow you to contribute to any of several 
different components of MacPorts.
Are there any components that you are particularly interested in?

You said you were having trouble narrowing down an area to work on.
Some possible suggestions to get you started:

*  Choose some tickets [2] and try to fix them.
Some tickets are open for a long time because they are difficult.
However, some tickets are still open just because no-one has put any effort 
into fixing them.
For example, “Base should know the installed version of the command line 
tools” [3] is fairly easy to fix.
There is a PortGroup that already does much of the heavy lifting [4].
I just have not gotten around to incorporating the PortGroup into the base 
code.

*  Choose some outdated ports and try to update them [5].
Running “port livecheck maintainer:nomaintainer” give a (very long) list of 
outdated unmaintained port.
You could try to update a few of them.
You could focus on areas (e.g. mathematics) that are of particular interest 
to you.
This would also get you a little more acquainted with Tcl if you are not 
already.

*. Fix an annoyance.
You said you have been following the project for a few months.
Are there any aspects that you think “there just has to be a better way.”
For me, these kinds of things have led to interesting projects (and 
research areas).
One fairly trivial example: several ports use something like 
“configure.env-append PATH=…:$env(PATH).”
I have always thought there has to be a better way to do that.

*  See if there are any mini-projects that people have on the back burner.
For example, I recently made a chance to the base code [6].
I am fairly certain that it is going to interact poorly with with the 
legacysupport-1.0.tcl PortGroup.
Again, I think the fix is fairly easy.
It is just I have not yet gotten a chance to work on it.

Especially if you are interested in GSoC, it is helpful for you to develop a 
history of code, reliability, and working with other developers.
The most important thing is to work on things that interest you.
GSoC requires a fair amount of time and effort, but it should be an enjoyable 
experience.

Since you said you have been following the project, I used some MacPorts 
vocabulary (e.g. PortGroup) without explanation.
Please feel free to ask for clarification if you are unfamiliar with any terms.

-Marcus


[1] https://trac.macports.org/wiki/SummerOfCode
[2] https://trac.macports.org/report/1?sort=created=0=1
[3] https://trac.macports.org/ticket/56318
[4] 
https://github.com/macports/macports-ports/blob/master/_resources/port1.0/group/cltversion-1.0.tcl
[5] https://trac.macports.org/wiki/SummerOfCode#orphanports
[6] 
https://github.com/macports/macports-base/commit/a86f95c5ab86ee52c8fec2271e005591179731de
[7] 
https://github.com/macports/macports-ports/blob/master/_resources/port1.0/group/legacysupport-1.0.tcl

> On Feb 1, 2020, at 7:17 AM, Tanvi Nerkar  wrote:
> 
> Dear Marcus,
> 
> I am a sophomore undergraduate student from Indian Institute of Technology 
> Kanpur. 
> 
> I am writing to you to see if you could use my help on this project as I am 
> very keen to help.
> 
> I have been following this project since November 2019, and I have a fair 
> idea of the issues and the way people resolve them.
> 
> I would like to contribute to this project as well. I was unable to narrow 
> down a specific area to work on, so it would be great if you helped me do 
> that.
> 
> If you are satisfied with the output I produce, I would like to convert my 
> work into a potential GSoC project.
> 
> Looking forward to a positive response!
> 
> Regards,
> Tanvi Nerkar
> Contact: tan...@iitk.ac.in | tanvinerkar...@gmail.com
> Website: http://home.iitk.ac.in/~tanvin/

Re: GSOC mentor candidates

[Marcus Calhoun-Lopez]

Yes, I would be willing to be a mentor.

-Marcus

> On Jan 28, 2020, at 10:20 AM, Mojca Miklavec  wrote:
> 
> Hi,
> 
> In order to apply for GSOC we need to publish an up-to-date idea list.
> 
> MacPorts base make a significant (80%?) portion of the ideas list, so
> it would be nice if we could make it clear as soon as possible whether
> we have ideally two mentors willing to mentor base projects.
> 
> Marcus, Sat, or anyone else: please raise your hands if you would be
> willing to participate this year as mentors, else we need to archive
> those ideas and only leave a much shorter list.
> 
> Thanks in advance,
>Mojca

Re: OpenBLAS fixed in Xcode 11.2

[Marcus Calhoun-Lopez]

The xcode_workaround-1.0.tcl PortGroup was designed so that the workaround is 
automatically dropped when using Xcode 11.3.

-Marcus

> On Dec 15, 2019, at 8:49 AM, Jack Howarth  
> wrote:
> 
> FYI, the gmp test suite failure in the t-powm test case when using core2 
> optimization with the default stack checking has been solved in the release 
> Xcode 11.3. So the current -fno-stack-checking workaround in the MacPorts gmp 
> package can be dropped in favor of just blacklisting Xcode 11.0 through 11.2.
> Jack
> 
> On Sat, Nov 9, 2019 at 10:57 AM Marcus Calhoun-Lopez 
>  wrote:
> This is an interesting idea, but there may be other factors at play.
> 
> GMP has definite ideas about which compiler flags to use.
> When CFLAGS is set, GMP completely ignores its own and assumes the user just 
> wants what is in CFLAGS.
> 
> Without CFLAGS, GMP uses, for example, -O2 -pedantic -fomit-frame-pointer 
> -m64 -mtune=core2 -march=core2.
> When CFLAGS is set, none of these flags are used.
> 
> Following your lead, I was able to pass all of the tests just by setting 
> CFLAGS (*without* -fcheck-stack).
> 
> -Marcus
> 
> > On Nov 9, 2019, at 8:19 AM, Jack Howarth  
> > wrote:
> > 
> > 
> > 
> > On Fri, Nov 8, 2019 at 10:17 PM Ryan Schmidt  
> > wrote:
> > On Nov 8, 2019, at 20:03, Joshua Root wrote:
> > 
> > > On 2019-11-9 10:28 , Jack Howarth wrote:
> > >> I just noticed a really bizarre aspect to this Xcode 11 bug. If you
> > >> build gmp manually from source with the default compiler flags in use...
> > >> 
> > >> ./configure
> > >> make
> > >> make check
> > >> 
> > >> the t-powm test case fails. However if you add -fstack-check
> > >> explicitly on CFLAGS and CXXFLAGS, the t-powm test case failure is
> > >> suppressed.
> > >> 
> > >> ./configure  CFLAGS='-O2 -fcheck-stack' CXXFLAGS='-O2 -fcheck-stack'
> > >> make
> > >> make check
> > > 
> > > Are the default compiler flags '-O2'?
> > 
> > MacPorts default optimization flag is -Os.
> > 
> > 
> > Same behavior...
> > 
> > ./configure  CFLAGS='-Os -fstack-check' CXXFLAGS='-Os -fstack-check'
> > make
> > make check
> > 
> > suppresses the failure
> > 
> > PASS: t-powm
> > 
> > with Xcode 11.2 in a manual build. Wonder how many of the remaining 
> > packages that are requiring -fno-check-stack could actually be 'fixed' by 
> > explicitly passing -fcheck-stack instead. Obviously that option disabled 
> > some of the problematic stack checking code that Apple's clang is 
> > automatically generating in the absence of the flag.
> >  
> 

Re: error: thread-local storage is not supported

[Marcus Calhoun-Lopez]

macOS has supported thread-local storage since Mac OS X Lion.
So __thread (GNU extension) and _Thread_local (C11) could be used.
However, the C++11 keyword was not supported until Xcode 8 [1,2].

There is a pull request that attempts to improve the situation [3].

-Marcus

1. 
https://stackoverflow.com/questions/28094794/why-does-apple-clang-disallow-c11-thread-local-when-official-clang-supports/29929949#29929949
2. https://developer.apple.com/videos/play/wwdc2016-405/?time=354
3. https://github.com/macports/macports-base/pull/161

> On Nov 21, 2019, at 5:10 PM, Ken Cunningham  
> wrote:
> 
> Well, I’ll be hornswaggled.
> 
> Indeed it appears the compiler.thread_local_storage option in MacPorts is 
> well and truly broken. It basically only works on 10.6 and less (which is 
> where I often am, so I guess it always worked for me).
> 
> Marcus forgot to blacklist command_line clangs < 800. 
> 
> We’ll have to get that fixed.
> 
> 
> 
> Ken
> 
> 
> 
>> On Nov 21, 2019, at 11:42 AM, Renee Otten  wrote:
>> 
>> [sorry forgot to reply to the list earlier]
>> 
>> Thanks Ken, I am not sure if I can be of much help here - if you’d be 
>> willing to take a look that would be great! For now I’ll just blacklist 
>> clang below version 8.
>> 
>> Best,
>> Renee
>> 
>> 
>>> On Nov 21, 2019, at 12:52 PM, Ken Cunningham 
>>>  wrote:
>>> 
>>> yes, clang 800+ supported thread_local.
>>> 
>>> the open-source clangs support thread_local using libc++ way back, but 
>>> certainly macports-clang-5.0+. 
>>> 
>>> the c++11 gcc versions support it as well, using macports-installed 
>>> libstdc++.
>>> 
>>> All of that blacklisting logic is incorporated into Marcus' 
>>> compiler.thread_local command, and the guts are in 'portconfigure.tcl'. The 
>>> whole idea was to do it once there correctly, and then everyone could use 
>>> that instead of figuring it out themselves.
>>> 
>>> So -- if  that is not being honoured in the build, something weird must be 
>>> going on to make this build ignore base.
>>> 
>>> That's what I'll have to help sort out, using a VM or real system running 
>>> those OS versions.
>>> 
>>> Ken
>>> 
>>> 
>>> 
>>> On 2019-11-21, at 9:35 AM, Renee Otten wrote:
>>> 
 hi Ken, 
 
 
 see commits the following commits:
 
 https://github.com/macports/macports-ports/commit/d6e27064e928b43d412618ac7227cc016e461738
 https://github.com/macports/macports-ports/commit/c9e9e2a6263bbf9d915d9ba61877c80eed1a3089
 
 in the last commit, doing compiler.blacklist-append {clang < 700} does 
 make it build on OS X 10.8 and 10.9, but not on 10.10 yet, because there 
 it uses Clang “700.1.81”
 
 I’d appreciate your help with it, perhaps the issue is actually different 
 and I don’t understand it correctly. 
 
 Thanks again!
 Renee
>> 
> 

Re: WTB Qt 5.12LTS (port:qt512) (attn mcalhoun)

[Marcus Calhoun-Lopez]

> On Nov 17, 2019, at 8:09 AM, René J.V. Bertin  wrote:
> 
> On Sunday November 17 2019 07:03:50 Marcus Calhoun-Lopez wrote:
> 
>> Unfortunately, I cannot find the reference, but the consensus was 
>> essentially:
>> if the newest version works on all the platforms that the LTS does, then 
>> there is no reason to keep another Qt port around.
> 
> Hmmm, I think there is. There will probably come a time when the current 
> version drops support for OS versions, which will then depend on the LTS 
> version for bug fixes and security backports. If the timeline is going to be 
> the same as with 5.9LTS that means the OS versions concerned could be blocked 
> on 5.13 and/or 5.14 .

I am very sorry I cannot find the reference because this is the same argument I 
made.
(I cannot remember if this discussion was on the mailing list, the trac, or the 
GitHub comments.)
The rebuttal was that we can port any such changes to the newer Qt.
Just to be clear, this was not my argument, but I went with the consensus.

> 
>>> And in general, suppose it did exist: how good is the support for 
>>> installing port:qt51x manually and then getting the corresponding 
>>> dependencies on the correct, corresponding Qt version?
>> 
>> If a user, for example, on macOS Mojave installs qt511-qtbase, then all 
>> ports that use the qt5 PG should correctly recognize it is a valid Qt5 port 
>> that satisfies the dependencies.
> 
> Yes, but will they also pull in qt511-qtwhatever automatically? I know I must 
> have given this thought for my own Qt5 ports, but never tested it thoroughly 
> as far as I can remember.

Yes, it should pull in all of the necessary dependencies like qt511-qtwhatever.

> BTW, I'm getting reports of Qt 5.9.8 build errors on the latest 10.15 OS 
> version, errors which suggest C++ dialect issues despite the use of 
> `-std=c++11z`.
> 
> R.

Thank you for the heads-up.

-Marcus

Re: WTB Qt 5.12LTS (port:qt512) (attn mcalhoun)

[Marcus Calhoun-Lopez]

> May I ask why Qt 5.12LTS isn't in MacPorts, for those users who prefer 
> stability or want to develop against a stable version?

The last time we added a Qt version just because it was LTS, there were 
objections.
Unfortunately, I cannot find the reference, but the consensus was essentially:
if the newest version works on all the platforms that the LTS does, then there 
is no reason to keep another Qt port around.
I argued for keeping the LTS version, but there was little enthusiasm for it.

> And in general, suppose it did exist: how good is the support for installing 
> port:qt51x manually and then getting the corresponding dependencies on the 
> correct, corresponding Qt version?

If a user, for example, on macOS Mojave installs qt511-qtbase, then all ports 
that use the qt5 PG should correctly recognize it is a valid Qt5 port that 
satisfies the dependencies.
There are probably not a lot people using this configuration, so problems may 
still exist.
There is an issue with prebuilt binaries.
Some (most?) ports that depend on Qt will have to be (re)built from source to 
accommodate the different library versions.
`rev-upgrade` should catch these problems.
 
Not too long ago, there was a discussion on how to improve the situation [1], 
but no consensus was reached.

-Marcus

[1] https://lists.macports.org/pipermail/macports-dev/2018-May/thread.html#38834

> On Nov 17, 2019, at 6:01 AM, René J.V. Bertin  wrote:
> 
> Hi,
> 
> May I ask why Qt 5.12LTS isn't in MacPorts, for those users who prefer 
> stability or want to develop against a stable version?
> 
> And in general, suppose it did exist: how good is the support for installing 
> port:qt51x manually and then getting the corresponding dependencies on the 
> correct, corresponding Qt version?
> 
> R.

Re: OpenBLAS fixed in Xcode 11.2

[Marcus Calhoun-Lopez]

Yes, I am seeing the same error.
Like you, it is fixed for me with `-fno-stack-check`.

-Marcus

> On Nov 1, 2019, at 2:53 PM, Jack Howarth  
> wrote:
> 
>Is 'sudo port -d test gmp5' failing the t-powm test case for anyone 
> else under Xcode 11.2? Jeremy isn't seeing this failure (which on mymachine 
> is suppressed with -fno-stack-check).
> Jack
> 
> On Fri, Nov 1, 2019 at 6:08 AM Christopher Jones  
> wrote:
> Hi,
> 
> Good to hear. However, Xcode 11.2 has not fixed everything, as x265 still 
> seg. faults when build with clang from Xcode 11.2.
> 
> cheers Chris
> 
> > On 1 Nov 2019, at 12:49 am, Jack Howarth  
> > wrote:
> > 
> >  Although it wasn't fixed in Xcode 11.2 beta 2, the -fcheck-stack 
> > issues with OpenBLAS's test suite are fixed in the final Xcode 11.2 
> > released today.
> >  Jack
> 

Re: OpenBLAS fixed in Xcode 11.2

[Marcus Calhoun-Lopez]

There is a pull request* that attempts to consolidate these fixes in a 
PortGroup.
As always, any input is appreciated.

-Marcus

* https://github.com/macports/macports-ports/pull/5673

> On Nov 1, 2019, at 3:08 AM, Christopher Jones  
> wrote:
> 
> Hi,
> 
> Good to hear. However, Xcode 11.2 has not fixed everything, as x265 still 
> seg. faults when build with clang from Xcode 11.2.
> 
> cheers Chris
> 
>> On 1 Nov 2019, at 12:49 am, Jack Howarth  
>> wrote:
>> 
>> Although it wasn't fixed in Xcode 11.2 beta 2, the -fcheck-stack issues 
>> with OpenBLAS's test suite are fixed in the final Xcode 11.2 released today.
>> Jack
> 

Re: Please welcome the four GSOC projects this year

[Marcus Calhoun-Lopez]

Greeting, welcome, and congratulations.

Speaking only for myself, e-mail is the best way to communicate.
If the topic is of general interest or concern, a public forum might be 
appropriate (please CC me however).

This GSOC should be a great experience for all.

-Marcus

> On May 7, 2019, at 10:39 PM, Satryaji Aulia  wrote:
> 
> Hello everyone,
> 
> Thank you for selecting me for GSOC 2019, I'm very excited
> to contribute. Congratulations to the others too.
> 
> To my mentors Marcus and Clemens:
> For private communications, is e-mail the most effective way
> or do you prefer I message through something else?
> 
> I will track my deadlines and milestones through github issues
> on my macports-base fork, if that's ok with you. I'll set it up in a
> few days and ask for feedback.
> 
> Besides that, I'll use this period until May 27 to prepare for the
> coding period in general. Please let me know if you have any
> suggestions.
> 
> Thank you again, I look forward to your guidance in the future.
> 
> 
> 
> On Tue, May 7, 2019 at 5:27 AM Mojca Miklavec  wrote:
>> 
>> Dear MacPorters,
>> 
>> I'm happy to announce that MacPorts will be participating at Google's
>> GSOC with four awesome projects this year.
>> 
>> (Those who followed the heavy traffic on the development mailing list
>> are probably already aware of the excessive amount of traffic we
>> received in March and April.)
>> 
>> The selected projects are listed here:
>>https://summerofcode.withgoogle.com/organizations/4814249782673408/
>> 
>> 1.) Ahmad Satryaji Aulia: Phase Out Xcode Dependency
>> Mentored by: Marcus Calhoun-Lopez, Clemens Lang
>> A project touching the MacPorts base should remove the need to install
>> full Xcode.
>> 
>> 2.) Arjun Salyan: Web App (with API) to Collect PortIndex, Build
>> History and Installation Statistics
>> Mentored by: Mojca Miklavec, Umesh Singla
>> A standalone Django app telling you everything about individual ports.
>> 
>> 3.) Karan Sheth: Automating Packaging for Macports
>> Mentored by: Cyril Roelandt (upt author), Renee Otten
>> A python package to supersede cpan2port, pypi2port etc.
>> 
>> 4.) Rajdeep Bharati: Macports Custom Views Plugin for Buildbot
>> Mentored by: Pierre Tardy, Povilas Kanapickas (both from buildbot),
>> Mojca Miklavec
>> Upgrading our build infrastructure to the latest version of buildbot
>> with new and better views and other improvements.
>> 
>> I would like to congratulate all the students for getting selected and
>> thank all the mentors, in particular the three external ones who
>> jumped in to help us deal with the much higher amount of good
>> proposals than in previous years. We could sadly not accept all the
>> projects that we would have wanted.
>> 
>> The next three weeks are devoted to the community bonding period when
>> active participation of student is expected (with mentors' help) to
>> learn more about the tools and community, improve the planning and
>> potentially revise the goals and deadlines if needed, and get up to
>> speed for the great summer coding experience.
>> 
>> Mojca

Re: Cross-compilers broken

[Marcus Calhoun-Lopez]

Thank you for pointing this out.

I have opened a pull request that hopefully solve the problem
(https://github.com/macports/macports-ports/pull/4269).

I have also added a comment to the isl port
(https://github.com/macports/macports-ports/commit/1b5360823434eae6d46e8162f234919e1decf236).

-Marcus

> On May 5, 2019, at 11:47 PM, Mojca Miklavec  wrote:
> 
> Hi,
> 
> I lost the original thread about libgcc revbumps and good measures for
> revbumping ... but it seems that all cross-compilers are now broken
> and need a revbump.
> 
> Maybe we should put some comments on top of isl. From what I remember
> in the past isl would also often just work with newer gcc and for
> older ones one would need to use an older version.
> 
> Mojca

Re: [macports-ports] branch master updated: libgccX: rev-bump to match gccX following isl update

[Marcus Calhoun-Lopez]

> That took only took 10secs and a bit of time for the buildbots to build.

Respectfully, I would disagree with this assessment.
We are forcing everyone who builds from source (like myself) to rebuild a 
fairly large port.
For those of us with somewhat less than state of the art machines, this can 
require a bit more than a “bit of time.”

Of course, erring on the side of caution may be the correct choice.
It is certainly better than mysterious bug reports later on.
When I was testing the isl update, I saw no reason to rev update the libgccX 
ports, and I just wanted to make sure I didn’t miss anything.

Thanks for the details,
Marcus

> On May 5, 2019, at 12:37 PM, Christopher Jones  
> wrote:
> 
> Hi,
> 
>> On 5 May 2019, at 7:57 pm, Marcus Calhoun-Lopez  
>> wrote:
>> 
>> I am sorry for not being clear.
>> 
>>> If the builds differ, then it needs rev-bumpig.
>> 
>> The build is immaterial.
>> The files that get installed are the important thing.
>> 
>> If you look through https://packages.macports.org/libgcc9/,
>> libgcc9-9.1.0_0.darwin_18.x86_64.tbz2 and
>> libgcc9-9.1.0_1.darwin_18.x86_64.tbz2
>> install the exact same files, regardless of how they were built.
>> Therefore, there was no reason for the rev bump.
> 
> That may be the case, but without doing the build its hard to tell apriori.
> A dep changed, in a way that required gccX to be rev-bumped. I felt it better 
> to also rev-bump the libgccX just to be safe. That took only took 10secs and 
> a bit of time for the buildbots to build. I would rather do this than spend 
> much longer double checking each and every binary to see if anything changed 
> in them or not.
> 
> Chris
> 
>> 
>> -Marcus
>> 
>>> On May 5, 2019, at 8:56 AM, Christopher Jones  
>>> wrote:
>>> 
>>> 
>>> 
>>>> On 5 May 2019, at 4:48 pm, Marcus Calhoun-Lopez  
>>>> wrote:
>>>> 
>>>> Greetings.
>>>> 
>>>> With different versions of isl, the builds of libgccX may be slightly 
>>>> different, but if what is installed is *exactly* the same (see, e.g., 
>>>> https://packages.macports.org/libgcc9/).
>>> 
>>> If the builds differ, then it needs rev-bumpig. I’m not sure I understand 
>>> your  logic that suggests gccX needs rebuilding, but libgccX does not, when 
>>> both are exactly the same build. 
>>> 
>>> Chris
>>> 
>>>> Since there is no change in what is installed, then rev bumping is not 
>>>> necessary.
>>>> 
>>>> -Marcus
>>>> 
>>>>> On May 5, 2019, at 8:25 AM, Chris Jones  wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> GccX and libgccX are built from exactly the same source, more or less the 
>>>>> same build.  Only differ in what gets installed. Both therefore depend on 
>>>>> isl, so both needed rev bumping when it was updated.
>>>>> 
>>>>> Chris
>>>>> 
>>>>>> On 5 May 2019, at 4:08 pm, Marcus Calhoun-Lopez  
>>>>>> wrote:
>>>>>> 
>>>>>> Please forgive my ignorance, but could you please say a little more 
>>>>>> about the rationale behind this change?
>>>>>> Please correct me if I am wrong, but I thought that only the GCC 
>>>>>> compilers (not the libraries) depended on isl.
>>>>>> When the isl library name changes, must the compiler also be updated, as 
>>>>>> seems to have happened in the change?
>>>>>> If so, I will be sure to do so in the future.
>>>>>> 
>>>>>> Also, is there an advantage to having the library and compiler revision 
>>>>>> be the same?
>>>>>> If so, perhaps they should share the same variable.
>>>>>> 
>>>>>> Thanks,
>>>>>> Marcus
>>>>>> 
>>>>>> 
>>>>>>> On May 5, 2019, at 1:40 AM, Chris Jones  
>>>>>>> wrote:
>>>>>>> 
>>>>>>> Chris Jones (cjones051073) pushed a commit to branch master
>>>>>>> in repository macports-ports.
>>>>>>> 
>>>>>>> 
>>>>>>> https://github.com/macports/macports-ports/commit/cac02e0a97f2d7af9f8526b88631d1c3aca8ebf8
>>>>>>> 
>>>>>>> The following commit(s) were added to refs/heads/master by this push:
>>>>>>&g

Re: [macports-ports] branch master updated: libgccX: rev-bump to match gccX following isl update

[Marcus Calhoun-Lopez]

I am sorry for not being clear.

> If the builds differ, then it needs rev-bumpig.

The build is immaterial.
The files that get installed are the important thing.

If you look through https://packages.macports.org/libgcc9/,
libgcc9-9.1.0_0.darwin_18.x86_64.tbz2 and
libgcc9-9.1.0_1.darwin_18.x86_64.tbz2
install the exact same files, regardless of how they were built.
Therefore, there was no reason for the rev bump.

-Marcus

> On May 5, 2019, at 8:56 AM, Christopher Jones  
> wrote:
> 
> 
> 
>> On 5 May 2019, at 4:48 pm, Marcus Calhoun-Lopez  
>> wrote:
>> 
>> Greetings.
>> 
>> With different versions of isl, the builds of libgccX may be slightly 
>> different, but if what is installed is *exactly* the same (see, e.g., 
>> https://packages.macports.org/libgcc9/).
> 
> If the builds differ, then it needs rev-bumpig. I’m not sure I understand 
> your  logic that suggests gccX needs rebuilding, but libgccX does not, when 
> both are exactly the same build. 
> 
> Chris
> 
>> Since there is no change in what is installed, then rev bumping is not 
>> necessary.
>> 
>> -Marcus
>> 
>>> On May 5, 2019, at 8:25 AM, Chris Jones  wrote:
>>> 
>>> Hi,
>>> 
>>> GccX and libgccX are built from exactly the same source, more or less the 
>>> same build.  Only differ in what gets installed. Both therefore depend on 
>>> isl, so both needed rev bumping when it was updated.
>>> 
>>> Chris
>>> 
>>>> On 5 May 2019, at 4:08 pm, Marcus Calhoun-Lopez  
>>>> wrote:
>>>> 
>>>> Please forgive my ignorance, but could you please say a little more about 
>>>> the rationale behind this change?
>>>> Please correct me if I am wrong, but I thought that only the GCC compilers 
>>>> (not the libraries) depended on isl.
>>>> When the isl library name changes, must the compiler also be updated, as 
>>>> seems to have happened in the change?
>>>> If so, I will be sure to do so in the future.
>>>> 
>>>> Also, is there an advantage to having the library and compiler revision be 
>>>> the same?
>>>> If so, perhaps they should share the same variable.
>>>> 
>>>> Thanks,
>>>> Marcus
>>>> 
>>>> 
>>>>> On May 5, 2019, at 1:40 AM, Chris Jones  wrote:
>>>>> 
>>>>> Chris Jones (cjones051073) pushed a commit to branch master
>>>>> in repository macports-ports.
>>>>> 
>>>>> 
>>>>> https://github.com/macports/macports-ports/commit/cac02e0a97f2d7af9f8526b88631d1c3aca8ebf8
>>>>> 
>>>>> The following commit(s) were added to refs/heads/master by this push:
>>>>> 
>>>>>  new cac02e0  libgccX: rev-bump to match gccX following isl update
>>>>> 
>>>>> cac02e0 is described below
>>>>> 
>>>>> 
>>>>> commit cac02e0a97f2d7af9f8526b88631d1c3aca8ebf8
>>>>> 
>>>>> Author: Chris Jones 
>>>>> AuthorDate: Sun May 5 09:40:08 2019 +0100
>>>>> 
>>>>> 
>>>>> libgccX: rev-bump to match gccX following isl update
>>>>> 
>>>>> ---
>>>>> lang/gcc6/Portfile | 2 +-
>>>>> lang/gcc7/Portfile | 2 +-
>>>>> lang/gcc8/Portfile | 2 +-
>>>>> lang/gcc9/Portfile | 2 +-
>>>>> 4 files changed, 4 insertions(+), 4 deletions(-)
>>>>> 
>>>>> 
>>>>> diff --git a/lang/gcc6/Portfile b/lang/gcc6/Portfile
>>>>> 
>>>>> index e438b69..5966e88 100644
>>>>> 
>>>>> --- a/lang/gcc6/Portfile
>>>>> 
>>>>> +++ b/lang/gcc6/Portfile
>>>>> 
>>>>> @@ -9,7 +9,7 @@ namegcc6
>>>>> 
>>>>> epoch   3
>>>>> version 6.5.0
>>>>> revision4
>>>>> 
>>>>> -subport libgcc6 { revision 1 }
>>>>> 
>>>>> +subport libgcc6 { revision 4 }
>>>>> 
>>>>> platforms   darwin
>>>>> categories  lang
>>>>> maintainers nomaintainer
>>>>> 
>>>>> diff --git a/lang/gcc7/Portfile b/lang/gcc7/Portfile
>>>>> 
>>>>> index a4ce4f4..2f606fe 100644
>>>>> 
>>>>> --- a/lan

Re: [macports-ports] branch master updated: libgccX: rev-bump to match gccX following isl update

[Marcus Calhoun-Lopez]

Greetings.

With different versions of isl, the builds of libgccX may be slightly 
different, but if what is installed is *exactly* the same (see, e.g., 
https://packages.macports.org/libgcc9/).
Since there is no change in what is installed, then rev bumping is not 
necessary.

-Marcus

> On May 5, 2019, at 8:25 AM, Chris Jones  wrote:
> 
> Hi,
> 
> GccX and libgccX are built from exactly the same source, more or less the 
> same build.  Only differ in what gets installed. Both therefore depend on 
> isl, so both needed rev bumping when it was updated.
> 
> Chris
> 
>> On 5 May 2019, at 4:08 pm, Marcus Calhoun-Lopez  
>> wrote:
>> 
>> Please forgive my ignorance, but could you please say a little more about 
>> the rationale behind this change?
>> Please correct me if I am wrong, but I thought that only the GCC compilers 
>> (not the libraries) depended on isl.
>> When the isl library name changes, must the compiler also be updated, as 
>> seems to have happened in the change?
>> If so, I will be sure to do so in the future.
>> 
>> Also, is there an advantage to having the library and compiler revision be 
>> the same?
>> If so, perhaps they should share the same variable.
>> 
>> Thanks,
>> Marcus
>> 
>> 
>>> On May 5, 2019, at 1:40 AM, Chris Jones  wrote:
>>> 
>>> Chris Jones (cjones051073) pushed a commit to branch master
>>> in repository macports-ports.
>>> 
>>> 
>>> https://github.com/macports/macports-ports/commit/cac02e0a97f2d7af9f8526b88631d1c3aca8ebf8
>>> 
>>> The following commit(s) were added to refs/heads/master by this push:
>>> 
>>>new cac02e0  libgccX: rev-bump to match gccX following isl update
>>> 
>>> cac02e0 is described below
>>> 
>>> 
>>> commit cac02e0a97f2d7af9f8526b88631d1c3aca8ebf8
>>> 
>>> Author: Chris Jones 
>>> AuthorDate: Sun May 5 09:40:08 2019 +0100
>>> 
>>> 
>>>   libgccX: rev-bump to match gccX following isl update
>>> 
>>> ---
>>> lang/gcc6/Portfile | 2 +-
>>> lang/gcc7/Portfile | 2 +-
>>> lang/gcc8/Portfile | 2 +-
>>> lang/gcc9/Portfile | 2 +-
>>> 4 files changed, 4 insertions(+), 4 deletions(-)
>>> 
>>> 
>>> diff --git a/lang/gcc6/Portfile b/lang/gcc6/Portfile
>>> 
>>> index e438b69..5966e88 100644
>>> 
>>> --- a/lang/gcc6/Portfile
>>> 
>>> +++ b/lang/gcc6/Portfile
>>> 
>>> @@ -9,7 +9,7 @@ namegcc6
>>> 
>>> epoch   3
>>> version 6.5.0
>>> revision4
>>> 
>>> -subport libgcc6 { revision 1 }
>>> 
>>> +subport libgcc6 { revision 4 }
>>> 
>>> platforms   darwin
>>> categories  lang
>>> maintainers nomaintainer
>>> 
>>> diff --git a/lang/gcc7/Portfile b/lang/gcc7/Portfile
>>> 
>>> index a4ce4f4..2f606fe 100644
>>> 
>>> --- a/lang/gcc7/Portfile
>>> 
>>> +++ b/lang/gcc7/Portfile
>>> 
>>> @@ -9,7 +9,7 @@ namegcc7
>>> 
>>> epoch   3
>>> version 7.4.0
>>> revision3
>>> 
>>> -subport libgcc7 { revision 0 }
>>> 
>>> +subport libgcc7 { revision 3 }
>>> 
>>> platforms   darwin
>>> categories  lang
>>> maintainers nomaintainer
>>> 
>>> diff --git a/lang/gcc8/Portfile b/lang/gcc8/Portfile
>>> 
>>> index 884ee71..2eb4260 100644
>>> 
>>> --- a/lang/gcc8/Portfile
>>> 
>>> +++ b/lang/gcc8/Portfile
>>> 
>>> @@ -9,7 +9,7 @@ epoch   4
>>> 
>>> namegcc8
>>> version 8.3.0
>>> revision4
>>> 
>>> -subport libgcc8 { revision 3 }
>>> 
>>> +subport libgcc8 { revision 4 }
>>> 
>>> platforms   darwin
>>> categories  lang
>>> maintainers nomaintainer
>>> 
>>> diff --git a/lang/gcc9/Portfile b/lang/gcc9/Portfile
>>> 
>>> index 3a8815d..22278fa 100644
>>> 
>>> --- a/lang/gcc9/Portfile
>>> 
>>> +++ b/lang/gcc9/Portfile
>>> 
>>> @@ -8,7 +8,7 @@ epoch   2
>>> 
>>> namegcc9
>>> version 9.1.0
>>> revision1
>>> 
>>> -subport libgcc9 { revision 0 }
>>> 
>>> +subport libgcc9 { revision 1 }
>>> 
>>> platforms   darwin
>>> categories  lang
>>> maintainers nomaintainer
>>> 
>>> 
>> 
> 

Re: [macports-ports] branch master updated: libgccX: rev-bump to match gccX following isl update

[Marcus Calhoun-Lopez]

Please forgive my ignorance, but could you please say a little more about the 
rationale behind this change?
Please correct me if I am wrong, but I thought that only the GCC compilers (not 
the libraries) depended on isl.
When the isl library name changes, must the compiler also be updated, as seems 
to have happened in the change?
If so, I will be sure to do so in the future.

Also, is there an advantage to having the library and compiler revision be the 
same?
If so, perhaps they should share the same variable.

Thanks,
Marcus


> On May 5, 2019, at 1:40 AM, Chris Jones  wrote:
> 
> Chris Jones (cjones051073) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/cac02e0a97f2d7af9f8526b88631d1c3aca8ebf8
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new cac02e0  libgccX: rev-bump to match gccX following isl update
> 
> cac02e0 is described below
> 
> 
> commit cac02e0a97f2d7af9f8526b88631d1c3aca8ebf8
> 
> Author: Chris Jones 
> AuthorDate: Sun May 5 09:40:08 2019 +0100
> 
> 
> libgccX: rev-bump to match gccX following isl update
> 
> ---
>  lang/gcc6/Portfile | 2 +-
>  lang/gcc7/Portfile | 2 +-
>  lang/gcc8/Portfile | 2 +-
>  lang/gcc9/Portfile | 2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)
> 
> 
> diff --git a/lang/gcc6/Portfile b/lang/gcc6/Portfile
> 
> index e438b69..5966e88 100644
> 
> --- a/lang/gcc6/Portfile
> 
> +++ b/lang/gcc6/Portfile
> 
> @@ -9,7 +9,7 @@ namegcc6
> 
>  epoch   3
>  version 6.5.0
>  revision4
> 
> -subport libgcc6 { revision 1 }
> 
> +subport libgcc6 { revision 4 }
> 
>  platforms   darwin
>  categories  lang
>  maintainers nomaintainer
> 
> diff --git a/lang/gcc7/Portfile b/lang/gcc7/Portfile
> 
> index a4ce4f4..2f606fe 100644
> 
> --- a/lang/gcc7/Portfile
> 
> +++ b/lang/gcc7/Portfile
> 
> @@ -9,7 +9,7 @@ namegcc7
> 
>  epoch   3
>  version 7.4.0
>  revision3
> 
> -subport libgcc7 { revision 0 }
> 
> +subport libgcc7 { revision 3 }
> 
>  platforms   darwin
>  categories  lang
>  maintainers nomaintainer
> 
> diff --git a/lang/gcc8/Portfile b/lang/gcc8/Portfile
> 
> index 884ee71..2eb4260 100644
> 
> --- a/lang/gcc8/Portfile
> 
> +++ b/lang/gcc8/Portfile
> 
> @@ -9,7 +9,7 @@ epoch   4
> 
>  namegcc8
>  version 8.3.0
>  revision4
> 
> -subport libgcc8 { revision 3 }
> 
> +subport libgcc8 { revision 4 }
> 
>  platforms   darwin
>  categories  lang
>  maintainers nomaintainer
> 
> diff --git a/lang/gcc9/Portfile b/lang/gcc9/Portfile
> 
> index 3a8815d..22278fa 100644
> 
> --- a/lang/gcc9/Portfile
> 
> +++ b/lang/gcc9/Portfile
> 
> @@ -8,7 +8,7 @@ epoch   2
> 
>  namegcc9
>  version 9.1.0
>  revision1
> 
> -subport libgcc9 { revision 0 }
> 
> +subport libgcc9 { revision 1 }
> 
>  platforms   darwin
>  categories  lang
>  maintainers nomaintainer
> 
> 

Re: [macports-ports] branch master updated: py-sphinxcontrib-applehelp: add support for Py 27 34 35 36

[Marcus Calhoun-Lopez]

According to the PyPI website, some fo the python versions that were added 
during this commit are not supported.
Are there reasons to suspect that PyPI is being overly conservative?

The same is true for other recent commits to py-sphinxcontrib-xyz ports.

Thanks,
Marcus

> On Apr 15, 2019, at 7:42 AM, Michael Dickens  wrote:
> 
> Michael Dickens (michaelld) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/44a0f481c71f1b7c72203943c7dfa241dd62d2f4
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 44a0f48  py-sphinxcontrib-applehelp: add support for Py 27 34 35 36
> 
> 44a0f48 is described below
> 
> 
> commit 44a0f481c71f1b7c72203943c7dfa241dd62d2f4
> 
> Author: Michael Dickens 
> AuthorDate: Mon Apr 15 10:42:33 2019 -0400
> 
> 
> py-sphinxcontrib-applehelp: add support for Py 27 34 35 36
> 
> ---
>  python/py-sphinxcontrib-applehelp/Portfile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> 
> diff --git a/python/py-sphinxcontrib-applehelp/Portfile 
> b/python/py-sphinxcontrib-applehelp/Portfile
> 
> index c6e3ee0..ef86446 100644
> 
> --- a/python/py-sphinxcontrib-applehelp/Portfile
> 
> +++ b/python/py-sphinxcontrib-applehelp/Portfile
> 
> @@ -21,7 +21,7 @@ checksums   rmd160  
> c4afa2e1711623167a2d880c849fc91b59ba035b \
> 
>  sha256  
> edaa0ab2b2bc74403149cb0209d6775c96de797dfd5b5e2a71981309efab3897 \
>  size22086
>  
> 
> -python.versions 37
> 
> +python.versions 27 34 35 36 37
> 
>  
>  if {${name} ne ${subport}} {
>  depends_build-append \
> 
> 

Re: [macports-ports] branch master updated: isl: revert back to 0.20

[Marcus Calhoun-Lopez]

Thank you for the information.
Unfortunately, I upgraded to Xcode 10.2 already, so rebuilding GCC is not going 
to be possible for a little while at least.

-Marcus

> On Apr 3, 2019, at 5:52 AM, Chris Jones  wrote:
> 
> Hi,
> 
> I thought (at first) 0,20 -> 0.21 was a minor update and as such fine under 
> openmaintainer. I ran some checks here locally first, rebuild gcc, and it 
> looked OK. However, I then started to see some failures in the buildbots I 
> could not fully explain. In the end, I decided it best to revert back So 
> yes, sorry for the mess here.
> 
> Note, in the end one of the failures I saw was not at all related to isl, but 
> in fact an Xcode 10.2 issue with gcc. see
> 
> https://trac.macports.org/ticket/58260
> 
> I did though see other errors specific to isl on some older platforms. They 
> looked like c++11 issues, but adding the cxx11 portgroup did not help. It was 
> at this point I decided to stop mucking around and revert..
> 
> Chris
> 
> On 03/04/2019 1:46 pm, Marcus Calhoun-Lopez wrote:
>> isl has the openmaintainer policy, but as the maintainer, I would appreciate 
>> knowing more about the recent activity.
>> The commit message does not indicate why the version was reverted.
>> Did the new version break GCC?
>> At the very least we should probably document this kind of thing so that 
>> others (like me) don’t make the same mistake.
>> Thanks,
>> Marcus
>>> On Apr 2, 2019, at 10:32 PM, Chris Jones  wrote:
>>> 
>>> Chris Jones (cjones051073) pushed a commit to branch master
>>> in repository macports-ports.
>>> 
>>> 
>>> https://github.com/macports/macports-ports/commit/cd2b8b27b5d5bc199a9e8df9b4fb32d1ed3ef915
>>> 
>>> The following commit(s) were added to refs/heads/master by this push:
>>> 
>>>  new cd2b8b2  isl: revert back to 0.20
>>> 
>>> cd2b8b2 is described below
>>> 
>>> 
>>> commit cd2b8b27b5d5bc199a9e8df9b4fb32d1ed3ef915
>>> 
>>> Author: Chris Jones 
>>> AuthorDate: Wed Apr 3 06:32:32 2019 +0100
>>> 
>>> 
>>> isl: revert back to 0.20
>>> 
>>> ---
>>>  devel/isl/Portfile | 11 +--
>>>  lang/gcc6/Portfile |  4 ++--
>>>  lang/gcc7/Portfile |  4 ++--
>>>  lang/gcc8/Portfile |  4 ++--
>>>  lang/gcc9/Portfile |  4 ++--
>>>  5 files changed, 13 insertions(+), 14 deletions(-)
>>> 
>>> 
>>> diff --git a/devel/isl/Portfile b/devel/isl/Portfile
>>> 
>>> index 1a79760..d7004f7 100644
>>> 
>>> --- a/devel/isl/Portfile
>>> 
>>> +++ b/devel/isl/Portfile
>>> 
>>> @@ -2,13 +2,12 @@
>>> 
>>>PortSystem  1.0
>>>  PortGroup   muniversal 1.0
>>> 
>>> -PortGroup   cxx11 1.1
>>> 
>>>nameisl
>>>  conflicts   isl-devel
>>>  
>>> -epoch   2
>>> 
>>> -version 0.21
>>> 
>>> +epoch   3
>>> 
>>> +version 0.20
>>> 
>>>categories  devel math
>>>  platforms   darwin
>>> 
>>> @@ -35,9 +34,9 @@ depends_lib port:gmp
>>> 
>>>  master_siteshttp://isl.gforge.inria.fr
>>>  use_bzip2   yes
>>>  
>>> -checksums   rmd160  181ded304f27fc556e41a0cac13d240672d6fe9b \
>>> 
>>> -sha256  
>>> d18ca11f8ad1a39ab6d03d3dcb3365ab416720fcb65b42d69f34f51bf0a0e859 \
>>> 
>>> -size1820796
>>> 
>>> +checksums   rmd160  68464147f6c392876456c18faaf95d17d2800acc \
>>> 
>>> +   sha256  
>>> b587e083eb65a8b394e833dea1744f21af3f0e413a448c17536b5549ae42a4c2 \
>>> 
>>> +   size1727820
>>> 
>>>configure.args  --disable-silent-rules
>>>  
>>> diff --git a/lang/gcc6/Portfile b/lang/gcc6/Portfile
>>> 
>>> index 209f586..8220a7e 100644
>>> 
>>> --- a/lang/gcc6/Portfile
>>> 
>>> +++ b/lang/gcc6/Portfile
>>> 
>>> @@ -7,8 +7,8 @@ PortGroup compiler_blacklist_versions 1.0
>>> 
>>>  namegcc6
>>>  epoch   2
>>>  version 6.5.0
>>> 
>>> -revision2
>>> 
>>> -subport libgcc6 { revision 2 }
>>> 
>>> +revision 

Re: [macports-ports] branch master updated: isl: revert back to 0.20

[Marcus Calhoun-Lopez]

isl has the openmaintainer policy, but as the maintainer, I would appreciate 
knowing more about the recent activity.
The commit message does not indicate why the version was reverted.
Did the new version break GCC?
At the very least we should probably document this kind of thing so that others 
(like me) don’t make the same mistake.

Thanks,
Marcus

> On Apr 2, 2019, at 10:32 PM, Chris Jones  wrote:
> 
> Chris Jones (cjones051073) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/cd2b8b27b5d5bc199a9e8df9b4fb32d1ed3ef915
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new cd2b8b2  isl: revert back to 0.20
> 
> cd2b8b2 is described below
> 
> 
> commit cd2b8b27b5d5bc199a9e8df9b4fb32d1ed3ef915
> 
> Author: Chris Jones 
> AuthorDate: Wed Apr 3 06:32:32 2019 +0100
> 
> 
> isl: revert back to 0.20
> 
> ---
>  devel/isl/Portfile | 11 +--
>  lang/gcc6/Portfile |  4 ++--
>  lang/gcc7/Portfile |  4 ++--
>  lang/gcc8/Portfile |  4 ++--
>  lang/gcc9/Portfile |  4 ++--
>  5 files changed, 13 insertions(+), 14 deletions(-)
> 
> 
> diff --git a/devel/isl/Portfile b/devel/isl/Portfile
> 
> index 1a79760..d7004f7 100644
> 
> --- a/devel/isl/Portfile
> 
> +++ b/devel/isl/Portfile
> 
> @@ -2,13 +2,12 @@
> 
>  
>  PortSystem  1.0
>  PortGroup   muniversal 1.0
> 
> -PortGroup   cxx11 1.1
> 
>  
>  nameisl
>  conflicts   isl-devel
>  
> 
> -epoch   2
> 
> -version 0.21
> 
> +epoch   3
> 
> +version 0.20
> 
>  
>  categories  devel math
>  platforms   darwin
> 
> @@ -35,9 +34,9 @@ depends_lib port:gmp
> 
>  master_siteshttp://isl.gforge.inria.fr
>  use_bzip2   yes
>  
> 
> -checksums   rmd160  181ded304f27fc556e41a0cac13d240672d6fe9b \
> 
> -sha256  
> d18ca11f8ad1a39ab6d03d3dcb3365ab416720fcb65b42d69f34f51bf0a0e859 \
> 
> -size1820796
> 
> +checksums   rmd160  68464147f6c392876456c18faaf95d17d2800acc \
> 
> + sha256  
> b587e083eb65a8b394e833dea1744f21af3f0e413a448c17536b5549ae42a4c2 \
> 
> + size1727820
> 
>  
>  configure.args  --disable-silent-rules
>  
> 
> diff --git a/lang/gcc6/Portfile b/lang/gcc6/Portfile
> 
> index 209f586..8220a7e 100644
> 
> --- a/lang/gcc6/Portfile
> 
> +++ b/lang/gcc6/Portfile
> 
> @@ -7,8 +7,8 @@ PortGroup compiler_blacklist_versions 1.0
> 
>  namegcc6
>  epoch   2
>  version 6.5.0
> 
> -revision2
> 
> -subport libgcc6 { revision 2 }
> 
> +revision3
> 
> +subport libgcc6 { revision 3 }
> 
>  platforms   darwin
>  categories  lang
>  maintainers nomaintainer
> 
> diff --git a/lang/gcc7/Portfile b/lang/gcc7/Portfile
> 
> index 39d64f1..85a7226 100644
> 
> --- a/lang/gcc7/Portfile
> 
> +++ b/lang/gcc7/Portfile
> 
> @@ -7,8 +7,8 @@ PortGroup compiler_blacklist_versions 1.0
> 
>  namegcc7
>  epoch   2
>  version 7.4.0
> 
> -revision1
> 
> -subport libgcc7 { revision 1 }
> 
> +revision2
> 
> +subport libgcc7 { revision 2 }
> 
>  platforms   darwin
>  categories  lang
>  maintainers nomaintainer
> 
> diff --git a/lang/gcc8/Portfile b/lang/gcc8/Portfile
> 
> index 44c9cb8..95224c5 100644
> 
> --- a/lang/gcc8/Portfile
> 
> +++ b/lang/gcc8/Portfile
> 
> @@ -7,8 +7,8 @@ PortGroup compiler_blacklist_versions 1.0
> 
>  epoch   2
>  namegcc8
>  version 8.3.0
> 
> -revision1
> 
> -subport libgcc8 { revision 1 }
> 
> +revision2
> 
> +subport libgcc8 { revision 2 }
> 
>  platforms   darwin
>  categories  lang
>  maintainers nomaintainer
> 
> diff --git a/lang/gcc9/Portfile b/lang/gcc9/Portfile
> 
> index b84c52f..96b7981 100644
> 
> --- a/lang/gcc9/Portfile
> 
> +++ b/lang/gcc9/Portfile
> 
> @@ -7,8 +7,8 @@ PortGroup   compiler_blacklist_versions 1.0
> 
>  epoch   2
>  namegcc9
>  version 9-20190331
> 
> -revision0
> 
> -subport libgcc-devel { revision 0 }
> 
> +revision1
> 
> +subport libgcc-devel { revision 1 }
> 
>  platforms   darwin
>  categories  lang
>  maintainers nomaintainer
> 
> 

Re: GSoC 2019 [Make Blacklisting MacPorts Compilers Easier]

[Marcus Calhoun-Lopez]

Greetings.

Learning Tcl should not be too difficult, especially since you are already 
familiar with other languages.
The GSoC website has a link to a Tcl tutorial [1].

What constitutes “low hanging fruit” depends on your experience level with 
MacPorts.
Do you own a Mac?
Have you used MacPorts before?

For the most part, the project you propose would involve modifying the 
compiler_blacklist_versions PortGroup [2].
If the word PortGroup is new to you, you might want to read through the 
MacPorts documentation [3].

If you are eager to jump right in to MacPorts development, you could attempt to 
take an “orphaned port” and update it.
If you run `port livecheck maintainer:nomaintainer`, you will find a great 
number of ports which are out of date or whose livecheck is broken.
You could then attempt a fix and submit a pull request [4].

If this has not answered your question, please feel free to ask for 
clarification.

-Marcus

[1] 
https://trac.macports.org/wiki/SummerOfCode#Whatyoushoulddobeforehandinginanapplication
[2] 
https://github.com/macports/macports-ports/blob/master/_resources/port1.0/group/compiler_blacklist_versions-1.0.tcl
[3] https://guide.macports.org
[4] https://guide.macports.org/#project.github

> On Mar 27, 2019, at 9:33 AM, Fatema Sherif  wrote:
> 
> I hope this email finds you well. I am a senior year student at Cairo 
> University. I am interested in the project idea in GSoC 2019  "Make 
> Blacklisting MacPorts Compilers Easier] ".
> I want to apply for summer internship in MacPorts but I don't know have 
> experience with Tcl. I wanted to know if it is ok and if I'll have time with 
> the tutorials.
> I am a good programmer in C,C++,Java,Android Programming, web development and 
> Python.
> I would like to proceed with the application and it would be nice to know 
> what I should do next. 
> I would like to know if you have relevant low hanging fruit so I'd get 
> clearer vision for plan in the proposal or I shall proceed with the proposal 
> directly.
> 
> Best regards,
> 

Re: GSoC 2019 [Phase out dependency on Xcode]

[Marcus Calhoun-Lopez]

Greetings.

Forgive me if this is obvious to you, but just to make sure we are on the same 
page, I will go into a little more detail than you probably want.
The first thing to understand is that adding support for `use_xcode` (and/or 
`use_command_line_tools`) is the *first step*.
This should be fairly easy.
After that, you would modify trace mode to assist maintainers in figuring out 
if changing `use_xcode` is *necessary*.
Trace mode is the part of the base code I am least familiar with, but I believe 
this is a reasonable goal.

Currently, the official policy is that MacPorts requires *both* Xcode and the 
command line tools need to be installed [1].
The `port` command issues warnings if either one is not installed [2].
That being said, several (many?, most?) ports build fine with just the command 
line tools.
There are at least a few ports that would build just fine with just Xcode (e.g. 
port that build with qmake [3]).
In a Portfile, if `use_xcode` were set to `no`, MacPorts would have to attempt 
to build the port with just the command line tools.
Just to be clear, `use_xcode` does not exist yet.
MacPorts does have *some* support for systems without Xcode, but the code is 
new, untested, and has not even made it into a released version of MacPorts [4].

After `use_xcode` is implemented, the next step would be to help maintainers 
determine if they should change it in a Portfile.
With my somewhat limited understating of trace mode, you might want to start 
with porttrace.tcl [5].
For example, if `use_xcode` is `no`, then some of the directories being added 
to the sandbox no longer make sense.

Here is the flow we have now:
A user installs a port.
If Xcode is not installed, a warning is issued, and maybe the port installs and 
maybe it doesn’t.

Here is the flow we would like:
A user installs a port.
If, in the Portfile, it is explicitly stated that Xcode is not needed, then 
Xcode is not used, regardless of whether it is installed or not [6].
The port builds successfully.
To facilitate the flow we would like, trace mode attempts to determine if Xcode 
is being accessed and used, which would be strong indicator that Xcode is 
needed.

If I have not satisfactorily answered your question, please feel free to ask 
for clarification.

-Marcus

[1] https://www.macports.org/install.php
[2] 
https://github.com/macports/macports-base/blob/45e62d7e9e7679a43075d1912c8d4a06c2abc6fe/src/port1.0/portutil.tcl#L3296
[3] https://doc.qt.io/qt-5/qmake-manual.html
[4] 
https://github.com/macports/macports-base/commit/76a804cc360924927fa8e2dfa41c761a19d17f3b#diff-98449d939df165f9b8cc4d1aab90ed2c
[5] 
https://github.com/macports/macports-base/blob/master/src/port1.0/porttrace.tcl
[6] https://trac.macports.org/wiki/ReproducibleBuilds

> On Mar 29, 2019, at 1:35 AM, Satryaji Aulia  wrote:
> 
> Hi Marcus, I’m a final-year student from University of Indonesia interested 
> in contributing to MacPort, and I’m working on my proposal right now.
> 
> I’d like to ask about the Phase out dependency on Xcode project idea on the 
> Wiki page.
> 
> Just making sure of the flow: user/maintainer installs a Port using trace 
> mode (-t), if it turns out it the Port needs the full Xcode package, it 
> outputs:
> - An error message if full Xcode is not installed.
> - A warning message if use_xcode yes in the Portfile is not set.
> Thus, all the contributions are to be made on the macports-base repo. Correct?
> 
> In achieving this, exactly which parts of the codebase need to be modified 
> and how do you detect that a package needs full Xcode?
> 
> I understand that trace mode reads filenames that are accessed using 
> DYLD_INSERT_LIBRARIES. Do we compare these filenames to a list of filenames 
> that are from the full Xcode?
> 
> Looking forward to your reply.
> satraul

Re: Update Qt5

[Marcus Calhoun-Lopez]

No problem.
I hope your work on ParaView goes well.

-Marcus

> On Mar 20, 2019, at 5:29 PM, Ruben Di Battista  
> wrote:
> 
> Mmmh. I’m officially dumb :).
> 
> Sorry for bothering, I did not see it was already up to date. 
> 
> Sorry!!
> 
> On 21 March 2019 at 01:20:32, Marcus Calhoun-Lopez (mcalh...@macports.org) 
> wrote:
> 
>> Qt 5 should already be at version 5.12.2. 
>> 
>> -Marcus 
>> 
>> > On Mar 20, 2019, at 5:19 PM, Ruben Di Battista  
>> > wrote: 
>> >  
>> > Hello,  
>> >  
>> > I’m working on pushing the new version of ParaView. It currently has 
>> > problems with Qt 5.11 and it’s reported in the Kitware Gitlab issue 
>> > tracker that with the new Qt (5.12.2) on Mojave, the problems vanish. Can 
>> > we bump up the Qt version so I’ll try to build with the latest commit of 
>> > ParaView and see if the problem is really solved? 
>> >  
>> > Thanks,  
>> >  
>> > _  
>> > -. .´ | 
>> > ', ; |∞∞ 
>> > ˜˜ |∞ RdB 
>> > ,., |∞∞ 
>> > .' '. | 
>> > -' `’ 
>> >  
>> >  
>> > https://rdb.is

Re: Update Qt5

[Marcus Calhoun-Lopez]

Qt 5 should already be at version 5.12.2.

-Marcus

> On Mar 20, 2019, at 5:19 PM, Ruben Di Battista  
> wrote:
> 
> Hello, 
> 
> I’m working on pushing the new version of ParaView. It currently has problems 
> with Qt 5.11 and it’s reported in the Kitware Gitlab issue tracker that with 
> the new Qt (5.12.2) on Mojave, the problems vanish. Can we bump up the Qt 
> version so I’ll try to build with the latest commit of ParaView and see if 
> the problem is really solved?
> 
> Thanks, 
> 
>   _   
> -. .´  |
>   ',  ;|∞∞
> ˜˜ |∞ RdB
> ,.,|∞∞
>   .'   '.  |
> -'   `’
> 
> 
> https://rdb.is

Re: Speed up trace mode Project GSoC

[Marcus Calhoun-Lopez]

Greetings Mihir,

I am responding to this message on the developer mailing list in case anyone 
else has more insight than I.

> Basically, user may have installed packages or files in past which reside in 
> certain locations.(e.g. /usr/local)


Although trace made may help identify problems with software installed in 
/opt/local (or /sw), the official policy of MacPorts is that installing 
software into /usr/local is unsupported [1].

> Now when MacPorts is installing a new package, the name of files may conflict 
> with those pre installed(by the user) and create unpredictable dependencies 
> unnecessarily increasing build time or errors.
> The function of trace mode is to scan all locations that the package to be 
> installed will access and hide files which are not needed.


Trace mode has a few uses.
* As you noted, it can help track down times when port look in /usr/local for 
its dependencies.
* It can help track down times when ports look in /sw (from Fink) for its 
dependencies.
* It can help track down times when ports look in /opt/local (instead of 
${prefix}, which is not *always* /opt/local) for dependencies.
* It can help track down times when ports look for dependencies installed by 
MacPorts do not *declare* those dependencies.
Yes, trace mode attempts to hide the files that are not part of the system and 
are not declared as dependencies of the port.
MacPorts then issues warnings that there was an attempt to access these 
“hidden” files.

As you noted, trace mode slows things down quite a bit.
It also breaks some ports.

> I don’t have any experience with tcl(But I have worked with scripting 
> languages such as unix shell scripting & python)


Learning Tcl should not be too difficult, especially since you are already 
familiar with other languages.
The GSoC website has a link to a Tcl tutorial [2].

Please let me know if I have not fully answered your questions.

-Marcus

[1] https://trac.macports.org/wiki/FAQ#usrlocal
[2] 
https://trac.macports.org/wiki/SummerOfCode#Whatyoushoulddobeforehandinginanapplication

> On Mar 17, 2019, at 12:27 AM, Mihir Luthra <1999mihir.lut...@gmail.com> wrote:
> 
> Hi there,
> 
> I wanted to contact you regarding the “Speed Up trace mode” project.
> I gave a quick read to the documentation to get the basic understanding of 
> MacPorts.
> 
> I am giving a small description on what I understood,
> 
> Basically, user may have installed packages or files in past which reside in 
> certain locations.(e.g. /usr/local)
> Now when MacPorts is installing a new package, the name of files may conflict 
> with those pre installed(by the user) and create unpredictable dependencies 
> unnecessarily increasing build time or errors.
> The function of trace mode is to scan all locations that the package to be 
> installed will access and hide files which are not needed.
> But enabling trace mode makes the build process really long.
> So what we have to do is optimise the trace mode library by using better data 
> structures or improvising it.
> 
> I have a really nice experience with C(almost 4 years now)
> I don’t have any experience with tcl(But I have worked with scripting 
> languages such as unix shell scripting & python)
> 
> 
> I would really appreciate getting some pieces of advice from you and if I 
> have misunderstood the project please consider giving me light of clarity.
> 
> Regards,
> 
> Mihir Luthra
> Student in B.Tech. CSE, ABESIT Ghaziabad, India
> +91 9810702672
> 

Re: [macports-ports] branch master updated: gmsh-devel: mark as obsolete; replace with gmsh

[Marcus Calhoun-Lopez]

The removal of octave-legacy was accidentally included in this commit.
It was time to remove octave-legacy, so there is no need to restore it, but it 
should have had its own commit.

My apologies for the error.

-Marcus

> On Mar 16, 2019, at 7:18 AM, Marcus Calhoun-Lopez  
> wrote:
> 
> Marcus Calhoun-Lopez (MarcusCalhoun-Lopez) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/bfad3ca1182d2a7a052aea81972128816cb49efa
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new bfad3ca  gmsh-devel: mark as obsolete; replace with gmsh
> 
> bfad3ca is described below
> 
> 
> commit bfad3ca1182d2a7a052aea81972128816cb49efa
> 
> Author: Marcus Calhoun-Lopez 
> AuthorDate: Sat Mar 16 07:17:38 2019 -0700
> 
> 
> gmsh-devel: mark as obsolete; replace with gmsh
> 
> 
> 
> gmsh is updated regularly, and gmsh-devel is seldom very far ahead.
> 
> ---
>  math/octave-legacy/Portfile | 22 --
>  science/gmsh/Portfile   | 19 ---
>  2 files changed, 4 insertions(+), 37 deletions(-)
> 
> 
> diff --git a/math/octave-legacy/Portfile b/math/octave-legacy/Portfile
> 
> deleted file mode 100644
> 
> index fd0e757..000
> 
> --- a/math/octave-legacy/Portfile
> 
> +++ /dev/null
> 
> @@ -1,22 +0,0 @@
> 
> -# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; 
> c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
> 
> -
> 
> -PortSystem  1.0
> 
> -
> 
> -replaced_by octave
> 
> -PortGroup   obsolete 1.0
> 
> -
> 
> -nameoctave-legacy
> 
> -version 3.8.2
> 
> -revision5
> 
> -categories  math science
> 
> -license GPL-3
> 
> -
> 
> -subport octave-devel-rc {
> 
> -version  4.2.0-rc4
> 
> -revision 6
> 
> -}
> 
> -
> 
> -subport octave-devel-release {
> 
> -version  4.0.3
> 
> -revision 6
> 
> -}
> 
> diff --git a/science/gmsh/Portfile b/science/gmsh/Portfile
> 
> index 1ac4c99..d7a82f5 100644
> 
> --- a/science/gmsh/Portfile
> 
> +++ b/science/gmsh/Portfile
> 
> @@ -8,7 +8,6 @@ PortGroup   linear_algebra 1.0
> 
>  PortGroup   muniversal 1.0
>  
>  namegmsh
> 
> -conflicts   gmsh-devel
> 
>  version 4.1.5
>  categories  science
>  platforms   darwin
> 
> @@ -107,18 +106,8 @@ variant getdp description {Enable GetDP solver} {
> 
>  configure.args-delete -DENABLE_GETDP=OFF
>  }
>  
> 
> -subport gmsh-devel {
> 
> -conflicts   gmsh
> 
> -
> 
> -fetch.type  git
> 
> -git.url https://gitlab.onelab.info/gmsh/gmsh.git
> 
> -git.branch  d28e0c8829ef6b21486c3cde9ec5962caf23cf2c
> 
> -# see https://gitlab.onelab.info/gmsh/gmsh/blob/master/CMakeLists.txt
> 
> -version 4.2.0
> 
> -revision0
> 
> -
> 
> -livecheck.type regexm
> 
> -livecheck.url  https://gitlab.onelab.info/gmsh/gmsh
> 
> -livecheck.version  ${git.branch}
> 
> -livecheck.regex"/gmsh/gmsh/commit/(\[a-zA-Z0-9\]+)"
> 
> +# please remove on 2020-03-16
> 
> +subport ${name}-devel {
> 
> +replaced_by ${name}
> 
> +PortGroup   obsolete 1.0
> 
>  }
> 
> 

Re: GSoC 2019 [Collect build statistics]

[Marcus Calhoun-Lopez]

> On Mar 8, 2019, at 7:45 AM, Arjun Salyan via macports-dev 
>  wrote:
> 
> Please help me with that 'build reproducibility' point and also how do I plan 
> from here (I know Django, but I am still learning about MacPorts)?

There is a site on our Wiki on reproducible builds: 
https://trac.macports.org/wiki/ReproducibleBuilds
Several other projects are interested in this concept (see, e.g., 
https://reproducible-builds.org and https://wiki.debian.org/ReproducibleBuilds).

-Marcus

Re: GSoC 2019 : No idea about Macports

[Marcus Calhoun-Lopez]

Greetings.

Welcome to the MacPorts project.

Learning Tcl should not be too difficult, especially since you are already 
familiar with other languages.
The GSoC website has a link to a Tcl tutorial: 
https://trac.macports.org/wiki/SummerOfCode#Whatyoushoulddobeforehandinginanapplication

I have a few questions.
Do you own a Mac?
Have you used MacPorts before?

Do you have any particular interest areas?
For example, are you interested in improving MacPorts itself (the base code)?
Are you interested in improving a current port?
Are you interest in brining new software to MacPorts?

The GSoC ideas do assume some level of familiarity with MacPorts.
If you haven’t already, you might want to install MacPorts and install a few 
ports (following https://www.macports.org/install.php and 
https://guide.macports.org).

-Marcus

> On Mar 6, 2019, at 6:13 AM, Ravi Rathee  wrote:
> 
> I want to apply for summer internship in MacPorts but I dont know anything 
> about it. 
> I am a good programmer in C,C++,Java,Android Programming, Ruby and Python. 
> But I have no experience in TcL.
> 
> I have read the basic GSoC documentation at your site but I couldn't 
> understand the project ideas.
> 
> I have no idea how to proceed from here. Please guide me so I can make a 
> great Proposal.
> Also I am curious to know what are my chances of selection, if I start 
> learning today. I really want to work in MacPorts.
> 
> Thank You

GSOC Ideas

[Marcus Calhoun-Lopez]

As part of the GSOC application, it would be good to update the “Projects” 
section of the wiki page [1].
Here are a few idea that I was able to come up with.
I would appreciate any feedback.

-Marcus

[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.
 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.

 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`.

 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.

 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.

 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 properly (from a 
MacPorts point of view).
 See https://github.com/macports/macports-ports/pull/3583.
 *) 75% of the muniversal PG is to get multiple runs of the 
configure/build/destroot phases.

 6. Allow a variant to more elegantly become “undefaulted.”
 When it was decided that support for the FLTK toolkit should no longer be 
the default in octave, the (previously default) variant fltk was renamed 
fltk_toolkit.
 There is another port (I cannot remember which one) that hacks together 
another solution to avoid renaming a previously default variant.
 Is there a better solution?

 7. Find a way to make mass revision increases easier.
 There are times when upgrading a library means increasing the revision of 
ALL of its dependencies (e.g. readline, icu, and libgcc).
 Finding all of these ports can be tricky and error prone.
 -) Some ports do not have an explicit dependency.
 -) Some ports do not explicitly set a revision variable.
 -) If there are sub-ports, then there might be multiple revision 
variables.
 Personally, I have a script that partially automates this process, but it 
is far from ideal.
 Is there a better way?

 8. Find a solution to the longstanding issue of std::locale being broken in 
GCC.
 See https://trac.macports.org/ticket/15653

 9. Prevent `port reclaim` from removing build dependencies.
 See 
https://lists.macports.org/pipermail/macports-users/2019-January/thread.html#46344

10. Improve the finding of dependencies.
  Finding dependencies can sometimes be difficult:
   *) Read the project documentation, which is sometimes incomplete.
   *) Read the code, but dependencies can be quite well hidden within the 
build system or the code itself.
   *) Run the port command in trace mode, which is excellent, but not 100%.
   *) Wait for the bug reports.
  Can this be improved?
  See https://trac.macports.org/wiki/SummerOfCode#dependencies-gen.

11.Give Portfile better access to CFLAGS, CXXFLAGS, etc.
 Currently, CFLAGS and the like are set late in the process (arch flags 
added, -pipe added, etc.).
 Of course, there are good reasons for this.
 Unfortunately, this means that there is no Portfile access to these values.
 This causes some ugly workarounds such as duplication of code from the 
base or `configure.cmd printenv` and `configure.post_args {>> 

Re: [macports-ports] branch master updated: nrpe, nsca: remove outdated ports

[Marcus Calhoun-Lopez]

Do we have a policy to decide when a port should be removed?
If not, this might be a good example for discussion.

> nrpe, nsca: remove outdated ports

> - Both ports are unmaintained ...
This is true, but there may well be people out there who are willing to spend a 
little time upgrading them from time to time, especially if livecheck is 
working.

> - Both ports are … several years out of date.
There is a more recent versions available at:
https://github.com/NagiosEnterprises/nrpe
and
https://github.com/NagiosEnterprises/nsca
It is not clear to me that either of these projects qualify as dead.

>  - Neither port has dependents.
There may be users who want them.

>  - The version of nrpe in MacPorts is having SSL-related build errors,
>see https://git.io/fhSt7

This has an easy fix: add openssl dependency.

Please understand, I do not have any need for either of these ports.
However, if these are the standards we use to remove ports, then there are 
probably quite a few ports that are on the chopping block.
It is better to delete a port until it is in better shape?
Once a port is deleted, there is almost no way someone like me would ever even 
know of its existence, so it is unlikely to return.
It is better to have a smaller number of better maintained ports?

Personally, I am hesitant to delete unmaintained ports as long as the upstream 
project is alive.
Every now and again, I look through the tickets to see if there is an orphan 
port I can quickly fix.

Thanks,
Marcus

Can buildbots open a window?

[Marcus Calhoun-Lopez]

In trying to fix one bug [1], I seem to have created another [2].
I have been unable to fix the second bug, so I am revisiting the first.

When building, octave tries to open a window (using Qt).
As far as I can tell, this caused an error with the buildbots [1].
Is it true that the buildbots cannot open a window?
If so, can anyone think of a workaround?

Thanks,
Marcus

[1] https://trac.macports.org/ticket/57288
[2] https://trac.macports.org/ticket/57850

Re: C++17

[Marcus Calhoun-Lopez]

Greetings,

There are two pull requests [1,2] that would allow C++17 with the line:
compiler.cxx_standard 2017

There are two stumbling blocks:
1) consensus has been elusive on the default values of 
compiler.cxx_standard and compiler.c_standard [3,4]
2) there is a concern that the change would negatively impact performance 
to an unacceptable level [5].

1) is easy to fix once we decide.
It does not matter to me personally since I do not use the older systems.

I am not sure how to fix 2) since I do not know how to implement caching in the 
base code.

Please forgive me if this is more information than was requested, but I am 
hoping to move this pull request forward, and any help would be appreciated.

-Marcus

[1] https://github.com/macports/macports-base/pull/88
[2] https://github.com/macports/macports-ports/pull/2772
[3] https://github.com/macports/macports-base/pull/88#discussion_r193841635
[4] https://github.com/macports/macports-base/pull/88#discussion_r228771280
[5] https://github.com/macports/macports-base/pull/88#issuecomment-435279559

> On Dec 8, 2018, at 12:17 PM, Mojca Miklavec  wrote:
> 
> Hi,
> 
> What's the up-to-date recommendation for ports requiring C++17?
> 
> There were several different approaches, some of them probably still
> in PR queue, and I kind of lost track about what a port should do now
> to minimize the effort & copy-paste errors, both now and in the
> future.
> 
> (I would like to avoid the error-prone process of manually
> blacklisting a zillion of compilers in each individual port.)
> 
> Thank you,
>Mojca

Request for help with libedit

[Marcus Calhoun-Lopez]

A recent update to libedit is causing issues with Python [1].
I have tracked down the upstream changes that caused the problems and reverted 
them in a pull request [2].
I will attempt to reach out to the upstream developers, but I cannot quite tell 
if upstream is a project [3] or an operating system [4].

Would anyone more knowledgeable than I about libedit like to comment before I 
merge the pull request?
If at all possible, I would like to not carry these patches around forever.

Thanks,
Marcus

[1] https://trac.macports.org/ticket/57584
[2] 
https://github.com/macports/macports-ports/pull/3037/commits/fdd369a354c61ceab69d95334e05b59a8c3a0ff5
[3] http://thrysoee.dk/editline/
[4] http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libedit/?sortby=date#dirlist

Re: Creating a port for non-free software

[Marcus Calhoun-Lopez]

It would have to be something akin to the oracle-instantclient port, in which 
the user is responsible for putting the files in the correct location.
This is also how FreeBSD apparently supports GAMESS.

-Marcus


> On Oct 23, 2018, at 7:35 PM, Chris Jones  wrote:
> 
> Hi,
> 
> As i understand it reading the links below the user has to register 
> themselves, name and email etc., in order to get a password to allow access 
> to the downloads. I don’t really see how this is compatible with macports, 
> how would you integrate this into the port file ? 
> 
> Chris 
> 
>> On 24 Oct 2018, at 2:24 am, Marcus Calhoun-Lopez  
>> wrote:
>> 
>> Recently, there was a request to create a port for a software package called 
>> GAMESS [1].
>> After a little research, I found out that GAMESS is *not* free software [2].
>> Moreover, downloading GAMESS requires registration, and neither the source 
>> nor the binary can be redistributed [3].
>> I believe there is precedent for such a port [4], but I was wondering if fit 
>> within the ethos of MacPorts.
>> I have no personal need for the GAMESS, but if, as suggested by the 
>> reporter, it would be useful to others, I can put a little time into it.
>> 
>> If there is no way we can support such a setup, we should probably close the 
>> ticket as wontfix.
>> 
>> Thanks,
>> Marcus
>> 
>> [1] https://trac.macports.org/ticket/57395
>> [2] https://www.msg.chem.iastate.edu/gamess/License_Agreement.html
>> [3] https://www.msg.chem.iastate.edu/gamess/download.html
>> [4] 
>> https://github.com/macports/macports-ports/blob/master/databases/oracle-instantclient/Portfile
> 

Creating a port for non-free software

[Marcus Calhoun-Lopez]

Recently, there was a request to create a port for a software package called 
GAMESS [1].
After a little research, I found out that GAMESS is *not* free software [2].
Moreover, downloading GAMESS requires registration, and neither the source nor 
the binary can be redistributed [3].
I believe there is precedent for such a port [4], but I was wondering if fit 
within the ethos of MacPorts.
I have no personal need for the GAMESS, but if, as suggested by the reporter, 
it would be useful to others, I can put a little time into it.

If there is no way we can support such a setup, we should probably close the 
ticket as wontfix.

Thanks,
Marcus

[1] https://trac.macports.org/ticket/57395
[2] https://www.msg.chem.iastate.edu/gamess/License_Agreement.html
[3] https://www.msg.chem.iastate.edu/gamess/download.html
[4] 
https://github.com/macports/macports-ports/blob/master/databases/oracle-instantclient/Portfile

Commit History vs User Convenience

[Marcus Calhoun-Lopez]

I was hoping to get some help with how best to balance commit history and user 
convenience.

I would like to make two unrelated changed to the GCC ports.
Each change requires a revision increase of all the GCC ports.

There seem to be a few options:
1) Create two separate pull requests and have them merged separately.
2) Create one pull request that increases the revision number only once for the 
two unrelated changes. 
3) Create one pull request with several commits. Each commit increases the 
revision number (for a total of two).

Personally, I believe option 3 is the best choice.
The history remains clean, and nobody has to rebuild GCC twice in a matter of a 
few days.
I have created such a pull request 
(https://github.com/macports/macports-ports/pull/2730).

However, the comments in the PR seem to indicate that option 2 or 3 is 
preferable.

I was hoping to see if others had any strong feelings about this.
Ultimately, it makes little difference to me, but we have had concerns in the 
past about frequent rebuilds of large ports such as GCC.

Thanks,
Marcus

Pull Request Review

[Marcus Calhoun-Lopez]

I have finally gotten around to cleaning up the history of the pull request: 
https://github.com/macports/macports-base/pull/88
The PR significantly alters the way that compilers are selected and handled.
I have tried to address all the concerns raised in the comments.
However, since this is a substantial change, any additional comments would be 
appreciated.

-Marcus

Re: Help implementing a py-pyside2 port?

[Marcus Calhoun-Lopez]

I will look into a better example.

The documentation is nearly nonexistent, and that is clearly a problem.
I will try to bump it up on my priority list.

-Marcus

> On Aug 18, 2018, at 5:11 PM, Perry E. Metzger  wrote:
> 
> On Sat, 18 Aug 2018 14:58:58 -0700 Marcus Calhoun-Lopez
>  wrote:
>> I can offer what help I can.
>> Do you have a specific concern yet?
>> 
>> Just from a very cursory look at PySide2, the port
>> py37-qscintilla-qt5 might provide a starting point.
> 
> The qscintilla Portfiles are some of the most complicated ones I've
> ever seen. I don't understand them very well. Are there any other
> Python + Qt5 ports out there? Alternatively, is there any
> documentation on the qt5 portgroup?
> 
> Perry
> 
> 
>> 
>> -Marcus
>> 
>>> On Aug 18, 2018, at 11:22 AM, Perry E. Metzger
>>>  wrote:
>>> 
>>> I'm interested in creating a port for PySide2 (the official Python
>>> bindings for Qt5) but I don't really have much experience
>>> packaging things for Qt. Would anyone be willing to advise me?
>>> 
>>> -- 
>>> Perry E. Metzgerpmetz...@macports.org  
>> 
> 
> 
> 
> -- 
> Perry E. Metzger  pmetz...@macports.org

Re: Help implementing a py-pyside2 port?

[Marcus Calhoun-Lopez]

I can offer what help I can.
Do you have a specific concern yet?

Just from a very cursory look at PySide2, the port py37-qscintilla-qt5 might 
provide a starting point.

-Marcus

> On Aug 18, 2018, at 11:22 AM, Perry E. Metzger  wrote:
> 
> I'm interested in creating a port for PySide2 (the official Python
> bindings for Qt5) but I don't really have much experience packaging
> things for Qt. Would anyone be willing to advise me?
> 
> -- 
> Perry E. Metzger  pmetz...@macports.org

Re: GCC Dependencies

[Marcus Calhoun-Lopez]

> On Aug 12, 2018, at 5:14 PM, Chris Jones  wrote:

Thank you for your response.

> What you are proposing seems to suggest no long making, for instance, libgcc6 
> depend on the libgcc7 or libgcc. This means if you install only libgcc6 you 
> will not get a complete runtime, only the incomplete part that provides. I am 
> not sure this is a good idea. For one it means all the old gcc versions have 
> to explicitly declare a dependency on all the libgcc versions, which is 
> currently not required, as each, once installed guarantees a complete runtime 
> via its dependencies. For me, this should not be changed.
You make a fair point, but it seems to me that the current situation is a 
combinations of two different approaches.
For example, libgcc6 currently has library dependencies on llibgcc and libgcc7.
If I understand correctly, this is in keeping with what you describe as the 
proper approach.
However, gcc6 has library dependencies on libgcc and libgcc7 and a runtime 
dependency on libgcc6.
This seems to already be the situation you would like to avoid.

It seems to me that we should either choose to have the primary responsibility 
of maintaining dependencies in the GCC or the libgcc ports, not a mixture of 
both.

> You also seem to be proposing moving all the gcc port dependencies on libgcc 
> to runtime. Please note the dependencies are not only required at runtime, 
> but are in a number of cases also required whilst building. 
Thank you for pointing this out.
This is news to be.
I had assumed that as GCC was being built, it relied solely on its local 
version of libgcc with no interaction with the installed version of libgcc.
The Portfile then just deletes the local version of libgcc.
Just for my own education, would you mind going into a little more detail on 
how GCC uses the installed version of libgcc?

Thanks,
Marcus

>> On 12 Aug 2018, at 7:47 pm, Marcus Calhoun-Lopez  
>> wrote:
>> 
>> Currently, the GCC dependencies on the various parts of libgcc seem somewhat 
>> inconsistent or at least difficult to follow.
>> Before I go to the trouble of creating a pull request, I thought someone 
>> might have some insights.
>> Here is what I propose:
>> 
>> gcc43, gcc44, gcc45:
>>   Library Dependencies: 
>>   Runtime Dependencies: libgcc45, libgcc6, libgcc7, libgcc
>> 
>> gcc46, gcc47, gcc48, gcc49, gcc5, gcc6:
>>   Library Dependencies: 
>>   Runtime Dependencies: libgcc6, libgcc7, libgcc
>> 
>> gcc7:
>>   Library Dependencies: 
>>   Runtime Dependencies: libgcc7, libgcc
>> 
>> gcc8:
>>   Library Dependencies: 
>>   Runtime Dependencies: libgcc
>> 
>> gcc9:
>>   Library Dependencies: 
>>   Runtime Dependencies: libgcc-devel
>> 
>> --
>> 
>> libgcc45:
>>   Library Dependencies:
>>   Runtime Dependencies:
>> 
>> libgcc6:
>>   Library Dependencies:
>>   Runtime Dependencies:
>> 
>> libgcc7:
>>   Library Dependencies: 
>>   Runtime Dependencies:
>> 
>> 
>> ==
>> This is the current status of things:
>> ==
>> 
>> gcc43, gcc44, gcc45:
>>   Library Dependencies: libgcc
>>   Runtime Dependencies: libgcc45 libgcc6
>> 
>> gcc46, gcc47, gcc48, gcc49, gcc5:
>>   Library Dependencies: libgcc
>>   Runtime Dependencies: libgcc6
>> 
>> gcc6:
>>   Library Dependencies: libgcc libgcc7
>>   Runtime Dependencies: libgcc6
>> 
>> gcc7:
>>   Library Dependencies: libgcc
>>   Runtime Dependencies: libgcc7
>> 
>> gcc8:
>>   Library Dependencies: libgcc
>>   Runtime Dependencies: 
>> 
>> gcc9:
>>   Library Dependencies: libgcc-devel
>>   Runtime Dependencies: 
>> 
>> --
>> 
>> libgcc45:
>>   Library Dependencies:
>>   Runtime Dependencies: 
>> 
>> libgcc6:
>>   Library Dependencies: llibgcc libgcc7
>>   Runtime Dependencies: 
>> 
>> libgcc7:
>>   Library Dependencies: llibgcc
>>   Runtime Dependencies: 
>> 
>> --
>> 
>> Port libgcc45 contains:
>> /opt/local/lib/libgcc/libobjc-gnu.2.dylib
>> 
>> 
>> Port libgcc6 contains:
>> /opt/local/lib/libgcc/libasan.3.dylib
>> /opt/local/lib/libgcc/libgfortran.3.dylib
>> 
>> 
>> Port libgcc7 (for ${os.major}>=10) contains:
>> /opt/local/lib/libgcc/libasan.4.dylib
>> /opt/local/lib/libgcc/libcilkrts.5.dylib
>> /opt/local/lib/libgcc/libgfortran.4.dylib
>> /opt/local/lib/libgcc/libubsan.0.dylib
>> 
>> 
>> libgcc and libgcc-devel conflict
>> libgcc depends on
>>   libgcc8 if ${os.major}>=10
>>   libgcc7 otherwise
> 

GCC Dependencies

[Marcus Calhoun-Lopez]

Currently, the GCC dependencies on the various parts of libgcc seem somewhat 
inconsistent or at least difficult to follow.
Before I go to the trouble of creating a pull request, I thought someone might 
have some insights.
Here is what I propose:

gcc43, gcc44, gcc45:
Library Dependencies: 
Runtime Dependencies: libgcc45, libgcc6, libgcc7, libgcc

gcc46, gcc47, gcc48, gcc49, gcc5, gcc6:
Library Dependencies: 
Runtime Dependencies: libgcc6, libgcc7, libgcc

gcc7:
Library Dependencies: 
Runtime Dependencies: libgcc7, libgcc

gcc8:
Library Dependencies: 
Runtime Dependencies: libgcc

gcc9:
Library Dependencies: 
Runtime Dependencies: libgcc-devel

--

libgcc45:
Library Dependencies:
Runtime Dependencies:

libgcc6:
Library Dependencies:
Runtime Dependencies:

libgcc7:
Library Dependencies: 
Runtime Dependencies:


==
This is the current status of things:
==

gcc43, gcc44, gcc45:
Library Dependencies: libgcc
Runtime Dependencies: libgcc45 libgcc6

gcc46, gcc47, gcc48, gcc49, gcc5:
Library Dependencies: libgcc
Runtime Dependencies: libgcc6

gcc6:
Library Dependencies: libgcc libgcc7
Runtime Dependencies: libgcc6

gcc7:
Library Dependencies: libgcc
Runtime Dependencies: libgcc7

gcc8:
Library Dependencies: libgcc
Runtime Dependencies: 

gcc9:
Library Dependencies: libgcc-devel
Runtime Dependencies: 

--

libgcc45:
Library Dependencies:
Runtime Dependencies: 

libgcc6:
Library Dependencies: llibgcc libgcc7
Runtime Dependencies: 

libgcc7:
Library Dependencies: llibgcc
Runtime Dependencies: 

--

Port libgcc45 contains:
  /opt/local/lib/libgcc/libobjc-gnu.2.dylib


Port libgcc6 contains:
  /opt/local/lib/libgcc/libasan.3.dylib
  /opt/local/lib/libgcc/libgfortran.3.dylib


Port libgcc7 (for ${os.major}>=10) contains:
  /opt/local/lib/libgcc/libasan.4.dylib
  /opt/local/lib/libgcc/libcilkrts.5.dylib
  /opt/local/lib/libgcc/libgfortran.4.dylib
  /opt/local/lib/libgcc/libubsan.0.dylib


libgcc and libgcc-devel conflict
libgcc depends on
libgcc8 if ${os.major}>=10
libgcc7 otherwise

Re: Pull Request Etiquette

[Marcus Calhoun-Lopez]

Thank you for the advice.

I do not believe I was clear.
The pull request is *not* mine.
I did, however, use it as a staring point for local changes.

Thanks,
Marcus

> On May 19, 2018, at 3:17 PM, Helmut K. C. Tessarek <tessa...@evermeet.cx> 
> wrote:
> 
> Hello,
> 
> On 2018-05-20 00:06, Marcus Calhoun-Lopez wrote:
>> Does anyone have any suggestions on the proper way forward?
> 
> It's a PR, you are the owner. Rebase and force push.
> 
> Unless there's a reason to keep the history there's no reason why not to
> force push.
> 
>> It seems inefficient to attempt to describe the changes in the current pull 
>> request comment section.
> 
> It depends. Is there a reason to keep the process of getting where you
> are right now alive?
> 
>> It seems a little silly to open a competing pull request.
> 
> Yes. Unless you close the previous one.
> 
>> Should I create a pull request on the pull request?
> 
> No.
> 
> I'm not a MacPorts dev so my opinion has not much weight, but I do know
> how to work with git and in a team.
> 
> Cheers,
> K. C.
> 
> 
> -- 
> regards Helmut K. C. Tessarek  KeyID 0x172380A011EF4944
> Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944
> 
> /*
>   Thou shalt not follow the NULL pointer for chaos and madness
>   await thee at its end.
> */
> 

Pull Request Etiquette

[Marcus Calhoun-Lopez]

There is a pull request to update Octave to 4.4.0.
A significant amount of work has been put in to it.
While attempting to address some of the outstanding issues, my version had 
diverged in some significant ways.

Does anyone have any suggestions on the proper way forward?

It seems inefficient to attempt to describe the changes in the current pull 
request comment section.
It seems a little silly to open a competing pull request.
Should I create a pull request on the pull request?

I should note that my version is not quite ready for prime time.

Thank you,
Marcus

Re: Qt5 port group

[Marcus Calhoun-Lopez]

I believe this is possible.
However, as Ken pointed out in a previous email, we have two models we could 
follow:

1) The gtk3 +quarts vs gtk3 +x11 model
(Almost) every dependent port of gtk3 has quartz and x11 variants 
consistent with whatever gtk3 was installed with.
I *think* this could be done in the qt5 PortGroup.
Every port which uses PortGroup qt5 would get a qt5LTS variant (or a better 
name).
We already have some the machinery for the long delayed qt5kde variant.

2) The multiple LLVM/GCC versions model
Most of Qt 5 is installed into ${prefix}/libexec/qt5.
The exceptions are the cmake and pkgconfig files.
We could try to allow multiple simultaneous installations of Qt.
Each port would then be free to choose whichever is better.

I am not sure which (if either) would be a good design choice.

-Marcus

> On May 11, 2018, at 3:55 AM, Craig Treleaven  wrote:
> 
> Would there be some way to designate that a port wishes to rely only on LTS 
> versions?  AIUI, Qt 5.6 and 5.9 are currently the long term support versions. 
>  Qt 5.6 is supported on macOS 10.8, 10.9, 10.10, 10.11.  (“Deployment only on 
> 10.7”, they say.)  Qt 5.9 is supported on macOS 10.10, 10.11, 10.12.  
> Presumably it also works on 10.13.  Qt 5.5 is defacto supported on earlier 
> platforms.
> 
> qt5.get_default_name would effectively become:
> 
> os.major  9 through 11, qt55
> os.major 12 through 14, qt56
> os.major after13, qt59
> 
> When the Qt project releases a new LTS version, I would recommend that we NOT 
> recognize it as LTS for our purposes until at least the first major bug fix 
> release.
> 
> I hope I haven’t missed something blindingly obvious.
> 
> Craig
> 

Re: Qt5 port group

[Marcus Calhoun-Lopez]

Your points are well taken, but I am afraid I do not have any good solutions.

It it helps, the dependencies on Qt components are of the path: variety.
The idea was that if you wanted to stay at Qt 5.9, you only had to install 
qt59-qtbase.
However, this does not work well at all with prebuilt binaries.
I am not sure, but it might also be considered a violation of Reproducible 
Builds.

I am certainly open to suggestions to how to improve the situation.

-Marcus

> On May 9, 2018, at 5:00 PM, Craig Treleaven  wrote:
> 
>> On May 9, 2018, at 2:07 PM, Ryan Schmidt  wrote:
>> 
>> 
>> On May 9, 2018, at 07:18, Craig Treleaven wrote:
>> 
>>> On May 8, 2018, at 5:06 AM, Vincent Habchi wrote:
>>> 
 I was in the process of modifying the Qt5 Port group to allow for choosing 
 the Qt version one wants to link an application against using variants. 
 However, before I go further, I’d like to know if concurrent installations 
 of different Qt5 versions are supported in MacPorts. If not, what I do is 
 just futile.
>>> 
>>> Um, there are subports for each Qt5 version.  Picking one at random:
>>> 
>>> $ port info qt57-qtwebkit
>>> qt57-qtwebkit @5.7.1_1 (aqua)
>>> Variants: debug, examples, tests, universal
>>> 
>>> Description:  Tools and Module(s) for Qt Tool Kit 5: Qt WebKit and 
>>> Qt WebKit Widgets
>>> Homepage: http://qt.io
>>> 
>>> Extract Dependencies: xz
>>> Build Dependencies:   python27, pkgconfig
>>> Library Dependencies: fontconfig, icu, leveldb, webp, libxml2, libxslt, 
>>> zlib, sqlite3, qt57-qtdeclarative, qt57-qtlocation, qt57-qtmultimedia, 
>>> qt57-qtsensors, qt57-qtwebchannel, qt57-qtxmlpatterns, qt57-qtbase
>>> Conflicts with:   qt3, qt3-mac, qt56-qtbase, qt58-qtbase, qt5-qtbase, 
>>> qt55-qtbase, qt59-qtbase
>>> Platforms:macosx
>>> License:  {LGPL-3 GPL-3 OpenSSLException}
>>> Maintainers:  Email: mcalh...@macports.org, GitHub: 
>>> MarcusCalhoun-Lopez
>>>Policy: openmaintainer
>>> 
>>> Notice that the port depends on several Qt5 ports which are all specified 
>>> at the same level (“57”).  It conflicts with other versions of Qt.
>>> 
>>> Is that not sufficient?
>> 
>> My understanding of the fact that they conflict is that there is some latest 
>> version of Qt that is compatible with each version of macOS, and that by 
>> using the qt5 portgroup, one automatically receives that version. However, 
>> in practice, that does not appear to be the case. I see build failures of my 
>> Qt-using ports on some macOS versions because the chosen version of Qt is 
>> not compatible with that version of macOS.
> 
> The automatic upgrading that the portgroup does is a bit scary.  It seemed 
> like it was no time at all that we went from 5.7.1 to 5.10.  (Even though Qt, 
> at the time, said that they didn’t support the latest MacOS version.)  MythTV 
> needed some fixes for Qt 5.10 for some months after MacPorts moved forward.  
> I still need to do some testing to see if some interface glitches are present 
> with both 5.10 and (say) 5.5.  
> 
> I wish the portgroup gave some way to say “I don’t want to be on the bleeding 
> edge but I don’t want to be stuck at Qt 5.x forever, either”.  After all, the 
> vast majority of Linux installs are still running Qt 5.5.  Maybe this is 
> where variants could help.  I don’t have a good solution.
> 
> Craig
> 
> 

Re: Qt5 port group

[Marcus Calhoun-Lopez]

> On May 9, 2018, at 11:07 AM, Ryan Schmidt  wrote:
> 
> My understanding of the fact that they conflict is that there is some latest 
> version of Qt that is compatible with each version of macOS, and that by 
> using the qt5 portgroup, one automatically receives that version. However, in 
> practice, that does not appear to be the case. I see build failures of my 
> Qt-using ports on some macOS versions because the chosen version of Qt is not 
> compatible with that version of macOS.

I am aware of one instance of the wrong Qt component being installed for a 
particular system
(https://trac.macports.org/ticket/55651).
I am afraid I am unaware of any others.
Do you happen to remember which ones fail?

As a side note, I should have taken care of ticket #55651 by now, but 
QtWebEngine is a bit of corner case.
It does not seem to be widely used based on the number of Portfiles that use it.

-Marcus

Re: Compiler blacklist 'shorthand'

[Marcus Calhoun-Lopez]

There is some code written to do something like this.

The PortGroup is: 
https://github.com/macports/macports-ports/blob/master/_resources/port1.0/group/languages-1.0.tcl
The associated ticket is: https://trac.macports.org/ticket/55139

PortGroup languages 1.0
compiler.cxx_standard 2014

I have been intending to make a more concerted effort to get the code tested 
and eventually merged into the base.
Alas, however, other priorities keep getting in the way.

-Marcus

> On May 5, 2018, at 5:36 PM, Craig Treleaven  wrote:
> 
> Hi:
> 
> A couple of times recently, I’ve noticed boilerplate in ports that require 
> C++14.  After including the compiler_blacklist_versions portgroup, they then 
> do some gymnastics like:
> 
> compiler.blacklist  *gcc-3.* *gcc-4.* {*gcc-5.[0-3]} \
>{clang < 800} macports-clang-3.4 
> macports-clang-3.5 macports-clang-3.6 macports-clang-3.7
> 
> Would it not be easier to use and maintain if we had some shorthand 
> definitions.  Maybe something like:
> 
> compiler.blacklist  ${min_cxx14}
> 
> “min_cxx14” would be defined in the portgroup and then expand to the 
> above...assuming the above actually does a good job of blacklisting compilers 
> that don’t support C++14!
> 
> A major advantage is that if our list of non-C++14 compilers ever changes, it 
> only needs to be updated in one spot.
> 
> I suspect there would be a few other shorthand lists that could be 
> pre-defined.
> 
> Thoughts?
> 
> Craig

Re: Help with Pull Request

[Marcus Calhoun-Lopez]

This seems to have fixed both problems.

Thank you very much,
Marcus

> On May 3, 2018, at 4:17 AM, Rainer Müller <rai...@macports.org> wrote:
> 
> On 2018-05-03 12:14, Marcus Calhoun-Lopez wrote:
>> The only git commands I have been running (not in this order) are
>>git pull --rebase upstream master
>>git pull --rebase origin cargo-pg
>>git pull --rebase origin master
>>git push origin cargo-pg
>> where
>>cargo-pg is the name of my branch and upstream is
>>git remote add upstream https://github.com/macports/macports-ports.git
> 
> With 'git pull --rebase', you instruct git to take the specified remote
> and put all commits that are not in the remote on top of the branch.
> 
> git pull --rebase upstream master
> This brought in new commits from the master branch and put the local
> commits on top. This is what you wanted.
> 
> git pull --rebase origin cargo-pg
> This started with the cargo-pg branch, but then the new local commits
> (that came from master, but are not yet on cargo-pg), were put on top.
> Now you have the commits from cargo-pg first, then the commits that were
> done on master. This is the wrong order and not what you wanted.
> 
> Usually, you never want to rebase with anything else than
> upstream/master. You always want to start with the state of upstream,
> then put your new commits on top of that. You would first switch to the
> branch you want to work on, then run rebase:
> $ git checkout cargo-pg
> $ git pull --rebase upstream master
> 
> 
> After that advice for the future, there are two things to be fixed here.
> One is your master branch and one is the cargo-pg branch. Let's start
> with the cargo-pg branch.
> 
> Switch to the branch and rebase again on top of the current state of
> upstream/master. This will start with upstream, then put all local
> commits on top. Although you had "cloned" commits from upstream/master
> to this branch before, this will still do what you wanted. In case a
> commit results in an empty patch (has been applied before), it will be
> dropped during rebase. Therefore all the commits that are not meant to
> be on this branch will be gone after running these commands.
> 
> $ git checkout cargo-pg
> $ git pull --rebase upstream master
> (verify results in 'git log')
> $ git push --force origin cargo-pg
> 
> Now, let's go to the master branch. It is diverged because there is a
> commit for octave on it, then lots of "cloned" commits from
> upstream/master. Again, you can get rid of the "cloned" commits by
> running rebase again. As this one commit for octave is also already in
> upstream/master, there will be no local commits left after these commands:
> 
> $ git checkout master
> $ git pull --rebase upstream master
> (verify results in 'git log', should be identical to upstream/master)
> $ git push --force origin master
> 
> 
> 'git push --force' is considered dangerous because it allows you push a
> branch state that removes commits that were pushed previously. But
> sometimes this is exactly what you need to clean up.
> 
> 'git push --force' can only have unwanted effects when you are
> collaborating with others. By changing the branch such that commits are
> now missing, others might no longer be able to pull changes from the
> branch. However, these are branches in your personal fork, so you can do
> with the branches whatever you want. It is also unlikely that anyone
> else has a clone of your repository.
> 
> Hope this helps!
> 
> Rainer

Help with Pull Request

[Marcus Calhoun-Lopez]

Recently, I opened a pull request 
(https://github.com/macports/macports-ports/pull/1714/).
It originally had three changes:

https://github.com/macports/macports-ports/pull/1714/commits/59ff57cc3a8dacfb96f46fc3e902f2bfeae9ce02

https://github.com/macports/macports-ports/pull/1714/commits/5a4067d5fed62b9c728ac9a35c69d245bf45207c

https://github.com/macports/macports-ports/pull/1714/commits/27d91e9580d848aa0146ca8f1641484ac00bd910

Based on one of the comments, I added a fourth change:

https://github.com/macports/macports-ports/pull/1714/commits/00475440732ef92697b1d8e59fc62eac809a8d69

Unfortunately, I have also been attempting to keep both this branch and my 
master branch consistent with upstream.
My attempts seem to have cluttered up my pull request and messed up my master 
branch.
Now there are 21 changes instead of the desired 4 in the pull request.
On GitHub, I am told that “[t]his branch is 128 commits ahead, 128 commits 
behind macports:master,” which doesn’t sound good.
I am not sure if these issues are related.

The only git commands I have been running (not in this order) are
git pull --rebase upstream master
git pull --rebase origin cargo-pg
git pull --rebase origin master
git push origin cargo-pg
where
cargo-pg is the name of my branch and upstream is
git remote add upstream https://github.com/macports/macports-ports.git

Do I need to delete this pull request and start again?
Do I need to delete my fork and start again?
Deleting and restarting is, to my shame, my goto strategy with Git.

My hope is that I can do all my contributions through pull requests as it seems 
less dangerous.

I have tried to look up an answer online, but I would say that the quality  of 
advice on Git is … inconsistent.
I am not sure what sources to trust.
A surprisingly large number of them end with “git push --force” or “git push 
--force-with-lease.”
Of course, they include the caveat that this is also quite dangerous.

Is there any way to run
git config --global ability.level 'very_low'?

Any help would be appreciated.

Thanks,
Marcus

Re: Open Letter of Apology

[Marcus Calhoun-Lopez]

Unfortunately, there were 17 commits in total.
They are:
https://github.com/macports/macports-ports/commit/ad74231453310610fd7432adb93fb5110ad4157d
https://github.com/macports/macports-ports/commit/8129b740cee3af8924b19df302ca1ab5cc2c5be1
https://github.com/macports/macports-ports/commit/ef8a319b93196a8c24bc0ea786ceccdc72e2932a
https://github.com/macports/macports-ports/commit/2018e17bae76928704d88088e220dc036222a0f4
https://github.com/macports/macports-ports/commit/43fa62e3cd97c26170da5f061717b18ed41f8d7e
https://github.com/macports/macports-ports/commit/903a0f42ee73a1794f1bdb454d295bf27f16237e
https://github.com/macports/macports-ports/commit/ca60330d222f981707c1277b023b044176f0d47f
https://github.com/macports/macports-ports/commit/effc2886cf0bee00532024aa043b3fd3415d74cc
https://github.com/macports/macports-ports/commit/68a34f577814e3e5b3f444530262b109093da515
https://github.com/macports/macports-ports/commit/e3bd4e336adc623e396a0b9495b578a1a3cf2452
https://github.com/macports/macports-ports/commit/ab5c006fb4dc9bdf81be0516bf43bf6254f92f0b
https://github.com/macports/macports-ports/commit/ecb4c4162ecd507cf6edcb85d39958912304a78c
https://github.com/macports/macports-ports/commit/00388e9305f5189b9bfc3b5442e92c1b8766b883
https://github.com/macports/macports-ports/commit/d911e14f64df12efbcbdffa461da0337dbca1226
https://github.com/macports/macports-ports/commit/20e585feb55340dfe2a45d236f90fd2edecdb3e4
https://github.com/macports/macports-ports/commit/968ddf5b34bbba587c5c1335c24d79bb8e4ea481
https://github.com/macports/macports-ports/commit/24864aeda99bedbc183f882878df70e8b555aa0b

> On Apr 27, 2018, at 5:47 PM, Perry E. Metzger <pmetz...@macports.org> wrote:
> 
> On Fri, 27 Apr 2018 16:33:23 -0700 Marcus Calhoun-Lopez
> <mcalh...@macports.org> wrote:
>> Recently, I made some major changes to the cargo PortGroup and the
>> Portfiles of several people. My intent was:
>>  *) create a branch
>>  *) solicit feedback on the branch with the changes
>> 
>> Instead, I pushed the changes to master.
>> It was very careless of me, and I sincerely apologize to all those
>> I have inconvenienced.
>> 
>> I would like to mitigate my error as much as possible.
>> Does anyone know of an easy was to rollback my changes?
>> I am afraid my inability to correctly use Git is what caused this
>> problem in the first place.
> 
> Can you identify the set of commits in question? If you can tell us
> their identifiers, we can reverse them quite easily.
> 
> In the future, you might try forking the repository into your own
> GitHub account and checking *that* out in order to play with the
> operations you need to perform.

Thank you for the advice.
If I understand correctly, doing this will the allow me to make use of pull 
requests
(https://guide.macports.org/#project.github) to make final commits.

-Marcus

Open Letter of Apology

[Marcus Calhoun-Lopez]

Recently, I made some major changes to the cargo PortGroup and the Portfiles of 
several people.
My intent was:
*) create a branch
*) solicit feedback on the branch with the changes

Instead, I pushed the changes to master.
It was very careless of me, and I sincerely apologize to all those I have 
inconvenienced.

I would like to mitigate my error as much as possible.
Does anyone know of an easy was to rollback my changes?
I am afraid my inability to correctly use Git is what caused this problem in 
the first place.

-Marcus

Re: Adding dependencies using qt5 portgroup

[Marcus Calhoun-Lopez]

Sorry for the delay in getting this done.
Hopefully, it is fixed in
https://github.com/macports/macports-ports/commit/8641b4f6d571a1b083361c6e2c20b727bdaef065.
Adding
qt5.depends_runtime_component sqlite-plugin
to the Portfile should now add qt5-sqlite-plugin (or
qt5X-sqlite-plugin) as a runtime dependency.

-Marcus

On Fri, Jan 5, 2018 at 3:27 AM, Ryan Schmidt  wrote:
> On Dec 19, 2017, at 06:51, Ryan Schmidt wrote:
>
>> On Dec 14, 2017, at 19:02, Ryan Schmidt wrote:
>>
>>> I understand that when I'm using the qt5 portgroup and I want to add a 
>>> library dependency on a Qt component, I should use qt5.depends_component 
>>> instead of depends_lib-append, and that when I want to add a build 
>>> dependency I should use qt5.depends_build_component instead of 
>>> depends_build-append.
>>>
>>> I'm trying to make those changes in the QupZilla port, but I currently add 
>>> a runtime dependency on qt5-sqlite-plugin. I don't see a way in the qt5 
>>> portgroup to add a runtime dependency on a Qt component. What should I do?
>>
>> Any guidance on this?
>
> Was this use case not anticipated when designing the portgroup? Can it simply 
> not handle this right now? Can it be added to the portgroup?
>
> Marcus, you designed the portgroup, so I'm hoping you'll have some input.
>

Re: set merger_configure_env question

[Marcus Calhoun-Lopez]

On Sat, Dec 30, 2017 at 11:36 AM, Ken Cunningham
 wrote:
> configure.env-append libIDL_cv_long_long_format=ll
I would respectfully suggest that this is not a good fix.
As much as possible, we want the configure script to determine proper settings.
That is what all the "shenanigans" are for.

-Marcus

Re: set merger_configure_env question

[Marcus Calhoun-Lopez]

> # Required when cross-compiling.
> foreach arch ${configure.universal_archs} {
> lappend merger_configure_env(${arch})  libIDL_cv_long_long_format=ll
> }
This is almost certainly not what we want.
As much as possible, we want the configure script to determine proper settings.
Also, the code somewhat conflicts with the comment.

> # Required when cross-compiling.
> if { ${os.arch} eq "i386" } {
> if { ${os.major} >= 10 } {
> set merger_configure_env(ppc) libIDL_cv_long_long_format=ll
> }
> set merger_configure_env(ppc64)   libIDL_cv_long_long_format=ll
> } else {
> set merger_configure_env(i386)libIDL_cv_long_long_format=ll
> set merger_configure_env(x86_64)  libIDL_cv_long_long_format=ll
> }
>
>
> I don’t really understand why this block would do what it’s doing. Doesn’t
> seem to make sense to me. However, this same block, or variants thereof, are
> in many Portfiles, so it’s apparently the recommended way….
The configure script for libidl runs a program to determine the value
of libIDL_cv_long_long_format.
If the configure script thinks it is cross-compiling [1], then it will
not bother trying to run the test program because it thinks it can't.
That is the error you are getting.
For example, if os.arch is i386 and one of the
configure.universal_archs is ppc64, then the test program can be built
but can not be run.
That is why libIDL_cv_long_long_format must be set manually.

> Am I missing something? Are all those blocks in all those Portfiles
> incorrect?
They are probably correct just not exhaustive.
Without main.log, it is difficult to diagnose the problem.
Just a guess, but what is the value of "sysctl hw.cpu64bit_capable" on
the machine you are trying to build on?

-Marcus

[1] https://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html

Re: [macports-ports] 03/06: cxx11 PG: do not force the use of depends_lib-append

[Marcus Calhoun-Lopez]

On Thu, Dec 7, 2017 at 9:37 PM, Joshua Root <j...@macports.org> wrote:
> On 2017-12-8 10:01 , Marcus Calhoun-Lopez wrote:
>> On Mon, Dec 4, 2017 at 10:23 PM, Ryan Schmidt <ryandes...@macports.org> 
>> wrote:
>>>
>>> Also, why `global os.major`? It's not used...
>> os.major is used in line 52 [1].
>
> But not inside the register_gcc_dependents (now cxx11.add_dependencies)
> proc.

As far as I can tell, cxx11.add_dependencies (formally
register_gcc_dependents) begins on line 47 [1] and ends on line 58
[2].
os.major is used in line 52 [3].
Doesn't that put it within the procedure?
And doesn't that in turn necessitate the statement `global os.major`
on line 48 [4]?

Please forgive me if I am missing something obvious.

-Marcus

[1] 
https://github.com/macports/macports-ports/blob/443d1ccb2dedd2ab97bf354437473c11950936f2/_resources/port1.0/group/cxx11-1.1.tcl#L47
[2] 
https://github.com/macports/macports-ports/blob/443d1ccb2dedd2ab97bf354437473c11950936f2/_resources/port1.0/group/cxx11-1.1.tcl#L58
[3] 
https://github.com/macports/macports-ports/blob/443d1ccb2dedd2ab97bf354437473c11950936f2/_resources/port1.0/group/cxx11-1.1.tcl#L52
[4] 
https://github.com/macports/macports-ports/blob/443d1ccb2dedd2ab97bf354437473c11950936f2/_resources/port1.0/group/cxx11-1.1.tcl#L48

Re: [macports-ports] 01/04: qtkeychain: build out of source

[Marcus Calhoun-Lopez]

The cmake 1.1 PG is now used by qtkeychain [1].
The cmake 1.1 PG is also now consistent with  the cmake 1.0 PG [2].

[1] 
https://github.com/macports/macports-ports/commit/56742c7ae2b4e773efe507da209d63aeebc4a84c
[2] 
https://github.com/macports/macports-ports/commit/a11893408d88aed1752dfb7566493d86321f3fe6

-Marucs

On Mon, Dec 4, 2017 at 7:08 AM, Ryan Schmidt <ryandes...@macports.org> wrote:
>
> On Dec 3, 2017, at 08:37, Marcus Calhoun-Lopez wrote:
>
>> I am not aware of any reason why cmake 1.1 PG can not be used.
>> It was simply used in the original commit [1].
>>
>> The resulting builds are different, however.
>> For example in qtkeychain-qt4, the cmake file
>> QtKeychainLibraryDepends-macports.cmake is installed instead of
>> QtKeychainLibraryDepends-release.cmake.
>> This seems to intentional ([2] vs [3]).
>
> I agree that is intentional.
>
>> Further, the cmake 1.0 PG has a fairly recent change that I assume
>> should be applied to the cmake 1.1 PG as well [4].
>
> I assume that as well.
>
>> What is the policy for the cmake 1.1 PG?
>> Use it unless there is a very good reason not to?
>
> I think that's the intention, yes. I assume all ports using cmake 1.0 should 
> be switched to cmake 1.1, and then cmake 1.0 can be deleted.
>
>> Sorry for the long reply to a short question, but I only know the
>> basics of cmake and do not fully understand the differences between
>> the two portgroups [5].
>>
>> [1] 
>> https://github.com/macports/macports-ports/commit/441422b2dd33940dd39a779eb385ad720fa52736
>> [2] 
>> https://github.com/macports/macports-ports/blob/5d800fea139882eaf12171af1b96bfef686df4f6/_resources/port1.0/group/cmake-1.0.tcl#L75
>> [3] 
>> https://github.com/macports/macports-ports/blob/5d800fea139882eaf12171af1b96bfef686df4f6/_resources/port1.0/group/cmake-1.1.tcl#L88
>> [4] 
>> https://github.com/macports/macports-ports/commit/92ebb1f1652b7fdf2b7542832b4593b18acc7d8e
>> [5] https://trac.macports.org/ticket/52699
>>
>> On Sun, Dec 3, 2017 at 12:41 AM, Ryan Schmidt wrote:
>>> On Dec 2, 2017, at 10:13, Marcus Calhoun-Lopez wrote:
>>>
>>>> Marcus Calhoun-Lopez (MarcusCalhoun-Lopez) pushed a commit to branch master
>>>> in repository macports-ports.
>>>>
>>>>
>>>> https://github.com/macports/macports-ports/commit/e12355262540398d3ea36eb78af3b4b6876fa480
>>>>
>>>> commit e12355262540398d3ea36eb78af3b4b6876fa480
>>>>
>>>> Author: Marcus Calhoun-Lopez <mcalh...@macports.org>
>>>> AuthorDate: Sat Dec 2 09:02:41 2017 -0700
>>>>
>>>>
>>>>qtkeychain: build out of source
>>>
>>>> +cmake.out_of_source yes
>>>
>>> Any reason not to instead switch over to the cmake 1.1 portgroup, which 
>>> defaults to building out of source?
>>>
>

Re: [macports-ports] 01/04: qtkeychain: build out of source

[Marcus Calhoun-Lopez]

I am not aware of any reason why cmake 1.1 PG can not be used.
It was simply used in the original commit [1].

The resulting builds are different, however.
For example in qtkeychain-qt4, the cmake file
QtKeychainLibraryDepends-macports.cmake is installed instead of
QtKeychainLibraryDepends-release.cmake.
This seems to intentional ([2] vs [3]).

Further, the cmake 1.0 PG has a fairly recent change that I assume
should be applied to the cmake 1.1 PG as well [4].

What is the policy for the cmake 1.1 PG?
Use it unless there is a very good reason not to?

Sorry for the long reply to a short question, but I only know the
basics of cmake and do not fully understand the differences between
the two portgroups [5].

[1] 
https://github.com/macports/macports-ports/commit/441422b2dd33940dd39a779eb385ad720fa52736
[2] 
https://github.com/macports/macports-ports/blob/5d800fea139882eaf12171af1b96bfef686df4f6/_resources/port1.0/group/cmake-1.0.tcl#L75
[3] 
https://github.com/macports/macports-ports/blob/5d800fea139882eaf12171af1b96bfef686df4f6/_resources/port1.0/group/cmake-1.1.tcl#L88
[4] 
https://github.com/macports/macports-ports/commit/92ebb1f1652b7fdf2b7542832b4593b18acc7d8e
[5] https://trac.macports.org/ticket/52699

On Sun, Dec 3, 2017 at 12:41 AM, Ryan Schmidt <ryandes...@macports.org> wrote:
> On Dec 2, 2017, at 10:13, Marcus Calhoun-Lopez wrote:
>
>> Marcus Calhoun-Lopez (MarcusCalhoun-Lopez) pushed a commit to branch master
>> in repository macports-ports.
>>
>>
>> https://github.com/macports/macports-ports/commit/e12355262540398d3ea36eb78af3b4b6876fa480
>>
>> commit e12355262540398d3ea36eb78af3b4b6876fa480
>>
>> Author: Marcus Calhoun-Lopez <mcalh...@macports.org>
>> AuthorDate: Sat Dec 2 09:02:41 2017 -0700
>>
>>
>> qtkeychain: build out of source
>
>> +cmake.out_of_source yes
>
> Any reason not to instead switch over to the cmake 1.1 portgroup, which 
> defaults to building out of source?
>

Re: Question about compiler blacklisting (llvm-gcc for wxWidgets)

[Marcus Calhoun-Lopez]

On Thu, Nov 2, 2017 at 7:39 AM, Mojca Miklavec  wrote:
> I would have appreciated if Marcus would at least mention it before
> committing the new subport, I was just as confused when I saw it two
> days ago as you are.

At the time, I felt the change fell under the openmaintainer policy.
My apologies if my actions were discourteous.

For the sake of completeness, the reason I made the change was hugin-app[1].
A std::string was apparently passing between the boundary between C++
libraries, so
hugin-app and wxWidgets had to use the same C++ library.
Otherwise, strange segmentation faults would happen when the
std::string was destroyed.

[1] 
https://github.com/macports/macports-ports/commit/87b9fc402cf848b6c3cb899cf7106354ec82afcf

Request for Feedback

[Marcus Calhoun-Lopez]

I have created a new PortGroup to test possible changes to the base
code concerning compiler selection.
See https://trac.macports.org/ticket/55139.
I would greatly appreciate feedback from anyone knowledgable and/or
interested in compiler selection.

In the short term, the new PortGroup could be used to solve issues like
https://trac.macports.org/ticket/52468.

Thanks,
Marcus

Re: Help with Buildbot Logic

[Marcus Calhoun-Lopez]

The files are now available on packages.macports.org.
My apologies for the noise.

-Marcus

On Fri, Oct 20, 2017 at 1:32 PM, Mojca Miklavec
<mojca.miklavec.li...@gmail.com> wrote:
> On 20 October 2017 at 11:58, Marcus Calhoun-Lopez wrote:
>> I am trying to figure out whey llvm-5.0 and clang-5.0 are not located
>> on packages.macports.org for Mac OS X 10.6.
>
> Can you please check whether the packages are binary distributable? It
> could be that the package was already built, but not uploaded due to
> some licence conflict.
>
> Our setup doesn't really distinguish between ports that have been
> built and uploaded and ports that have been built, but not uploaded.
> We should not rebuild the port in any case. We could theoretically
> distinguish the difference or simply change the message (easier,
> doesn't change anything).
>
> Mojca

Help with Buildbot Logic

[Marcus Calhoun-Lopez]

I am trying to figure out whey llvm-5.0 and clang-5.0 are not located
on packages.macports.org for Mac OS X 10.6.
Below are the steps I have tried.
Can anyone help me understand where I am going wrong?

1) On my local virtual machine, llvm-5.0 and clang-5.0 build on Mac OS X 10.6
(see https://trac.macports.org/ticket/54996).

2) Neither llvm-5.0 nor clang-5.0 seem have been uploaded to
packages.macports.org
(see
http://packages.macports.org/llvm-5.0/?C=M;O=D
and
http://packages.macports.org/clang-5.0/?C=M;O=D).

3) I tried for force a rebuild of llvm-5.0 with the intention of then
forcing a rebuild of clang-5.0.
(see 
https://build.macports.org/builders/ports-10.6_i386_legacy-watcher/builds/9866).

4) The buildbot claims that llvm-5.0 has already been "built and uploaded"
even though it is not on packages.macports.org
(see 
https://build.macports.org/builders/ports-10.6_i386_legacy-watcher/builds/9866/steps/subports/logs/stdio).

5) The buildbot then tries to build lldb-5.0 and fails for a separate reason
(see 
https://build.macports.org/builders/ports-10.6_i386_legacy-builder/builds/29586/steps/install-port/logs/stdio).

Does [4] mean that the buildbot mistakenly think that llvm-5.0 is
already on packages.macports.org?
Does [5] mean that llvm-5.0 can not be built so long as lldb-5.0 fails to build?

Thank you,
Marcus

Re: [macports-ports] 03/04: gcc7: use configure.args-replace

[Marcus Calhoun-Lopez]

Thanks for pointing this out.

Fixed in 
https://github.com/macports/macports-ports/commit/e2e1dc15ef4a620c71cfb41290b492540163b8ff#diff-e5a8d1cf5b9a0eebaf9e2ad93a9867b9

-Marcus

On Sun, Oct 1, 2017 at 10:40 AM, Ryan Schmidt <ryandes...@macports.org> wrote:
>
> On Oct 1, 2017, at 12:19, Marcus Calhoun-Lopez wrote:
>
>> Marcus Calhoun-Lopez (MarcusCalhoun-Lopez) pushed a commit to branch master
>> in repository macports-ports.
>>
>>
>> https://github.com/macports/macports-ports/commit/51bf940169da452ac1563e76ec27318509a6ea37
>>
>> commit 51bf940169da452ac1563e76ec27318509a6ea37
>>
>> Author: Marcus Calhoun-Lopez <mcalh...@macports.org>
>> AuthorDate: Sun Oct 1 07:44:52 2017 -0700
>>
>>
>> gcc7: use configure.args-replace
>
>> -configure.args-delete --libdir=${prefix}/lib/${name}
>> -configure.args-append --libdir=${prefix}/lib/libgcc
>> +configure.args-replace \
>> +--libdir=${prefix}/lib/${name} \
>> +--libdir=${prefix}/lib/libgcc
>
>
> Please keep sets of ports as similar as possible; this reduces confusion. If 
> you make this change in gcc7, please make the equivalent change in all the 
> other gcc ports as well.
>
>
>

Re: [macports-ports] 11/11: lz4: use the right C++ compiler

[Marcus Calhoun-Lopez]

Thank you for noticing this.
It should be fixed in
https://github.com/macports/macports-ports/commit/129c7c7d5f3ee7902f844f6bcb5612181c165dbc.

-Marcus

On Sat, Sep 16, 2017 at 4:39 PM, Ryan Schmidt <ryandes...@macports.org> wrote:
>
>> On Sep 16, 2017, at 17:48, Marcus Calhoun-Lopez <mcalh...@macports.org> 
>> wrote:
>>
>> Marcus Calhoun-Lopez (MarcusCalhoun-Lopez) pushed a commit to branch master
>> in repository macports-ports.
>>
>>
>> https://github.com/macports/macports-ports/commit/84df47b322e354c0211df58f70cea91c2dcd246a
>>
>> commit 84df47b322e354c0211df58f70cea91c2dcd246a
>>
>> Author: Marcus Calhoun-Lopez <marcuscalhounlo...@gmail.com>
>> AuthorDate: Sat Sep 16 15:47:50 2017 -0700
>>
>>
>> lz4: use the right C++ compiler
>>
>>
>>
>> See https://trac.macports.org/wiki/UsingTheRightCompiler
>>
>> ---
>>  archivers/lz4/Portfile | 4 
>>  1 file changed, 4 insertions(+)
>>
>>
>> diff --git a/archivers/lz4/Portfile b/archivers/lz4/Portfile
>>
>> index ada6ed6..8a7dcaa 100644
>>
>> --- a/archivers/lz4/Portfile
>>
>> +++ b/archivers/lz4/Portfile
>>
>> @@ -30,9 +30,13 @@ destroot.args-append PREFIX=${prefix}
>>
>>  if { ![variant_isset universal] } {
>>  build.args-appendCC="${configure.cc} [get_canonical_archflags cc]"
>>  destroot.args-append CC="${configure.cc} [get_canonical_archflags cc]"
>> +build.args-appendCXX="${configure.cxx} [get_canonical_archflags cc]"
>> +destroot.args-append CXX="${configure.cxx} [get_canonical_archflags cc]"
>
> Should probably be "cxx" here, not "cc", though it currently doesn't make a 
> difference.
>
>
>

Re: [macports-ports] 05/11: triangle: fix universal build

[Marcus Calhoun-Lopez]

Thank you for caching this.
It should be fixed in
https://github.com/macports/macports-ports/commit/63f9d6e568e5b2a9ab7dd14d776ed7c64b5be329.

-Marcus

On Sat, Sep 16, 2017 at 4:43 PM, Ryan Schmidt <ryandes...@macports.org> wrote:
>
>> On Sep 16, 2017, at 17:47, Marcus Calhoun-Lopez <mcalh...@macports.org> 
>> wrote:
>>
>> Marcus Calhoun-Lopez (MarcusCalhoun-Lopez) pushed a commit to branch master
>> in repository macports-ports.
>>
>>
>> https://github.com/macports/macports-ports/commit/e9b61886655093d37a0691342924c20587495a8a
>>
>> commit e9b61886655093d37a0691342924c20587495a8a
>>
>> Author: Marcus Calhoun-Lopez <marcuscalhounlo...@gmail.com>
>> AuthorDate: Sat Sep 16 14:39:34 2017 -0700
>>
>>
>> triangle: fix universal build
>>
>> ---
>>  science/triangle/Portfile  | 21 ++---
>>  science/triangle/files/patch-makefile.diff | 28 
>>  2 files changed, 42 insertions(+), 7 deletions(-)
>>
>>
>> diff --git a/science/triangle/Portfile b/science/triangle/Portfile
>
>> +post-patch  {
>> +reinplace "s|__MACPORTS_CC__|${configure.cc}|g" ${worksrcpath}/makefile
>> +reinplace "s|__MACPORTS_PREFIX__|${prefix}|g" ${worksrcpath}/makefile
>> +if {[variant_isset universal]} {
>> +reinplace "s|__MACPORTS_CFLAGS__|${configure.cflags} 
>> ${configure.universal_cflags}|g" ${worksrcpath}/makefile
>> +} else {
>> +reinplace "s|__MACPORTS_CFLAGS__|${configure.cflags} 
>> ${configure.cc_archflags}|g" ${worksrcpath}/makefile
>> +}
>> +reinplace "s|__MACPORTS_LDFLAGS__|${configure.ldflags}|g" 
>> ${worksrcpath}/makefile
>>  }
>
> It's simpler to use [get_canonical_archflags cc] than to write a conditional 
> about the universal variant. The LDFLAGS probably also need 
> [get_canonical_archflags ld].
>
>
>> diff --git a/science/triangle/files/patch-makefile.diff 
>> b/science/triangle/files/patch-makefile.diff
>> new file mode 100644
>> index 000..15433ef
>> --- /dev/null
>> +++ b/science/triangle/files/patch-makefile.diff
>> @@ -0,0 +1,28 @@
>> +--- makefile.orig2005-07-27 17:22:01.0 -0700
>>  makefile 2017-09-10 00:15:00.0 -0700
>> +@@ -18,7 +18,7 @@
>> +
>> + # CC should be set to the name of your favorite C compiler.
>> +
>> +-CC = cc
>> ++CC = /usr/bin/clang
>> +
>> + # CSWITCHES is a list of all switches passed to the C compiler.  I strongly
>> + #   recommend using the best level of optimization.  I also strongly
>> +@@ -73,7 +73,7 @@
>> + #
>> + #   CSWITCHES = -O -DNO_TIMER -DLINUX -I/usr/X11R6/include -L/usr/X11R6/lib
>> +
>> +-CSWITCHES = -O -DLINUX -I/usr/X11R6/include -L/usr/X11R6/lib
>> ++CSWITCHES = -Os -arch x86_64 -arch i386
>> +
>> + # TRILIBDEFS is a list of definitions used to compile an object code 
>> version
>> + #   of Triangle (triangle.o) to be called by another program.  The file
>> +@@ -97,6 +97,7 @@
>> + all: $(BIN)triangle $(BIN)showme
>> +
>> + trilibrary: $(BIN)triangle.o $(BIN)tricall
>> ++$(CC) -dynamiclib -L/opt/local/lib -Wl,-headerpad_max_install_names 
>> -install_name /opt/local/lib/libtriangle.dylib -o libtriangle.dylib 
>> triangle.o
>> +
>> + $(BIN)triangle: $(SRC)triangle.c
>> + $(CC) $(CSWITCHES) -o $(BIN)triangle $(SRC)triangle.c -lm
>
> I think you've inadvertently committed this file with your placeholders 
> expanded.
>
>

Add --disable-tls to GCC?

[Marcus Calhoun-Lopez]

The file 
${prefix}/include/gcc6/c++/${build_arch}-apple-darwin${os.major}/bits/c++config.h
has different values for _GLIBCXX_HAVE_TLS on different platforms.
For ${os.major}  <  15, _GLIBCXX_HAVE_TLS is defined as 1.
For ${os.major} >= 15, _GLIBCXX_HAVE_TLS is undefined.
I am not sure why the availability of thread-local storage changed,
but for consistency, should --disable-tls be added to the GCC
configure script (see https://gcc.gnu.org/install/configure.html)?

The reason I bring this up is that the following code works macOS
Sierra and OS X El Capitan:
--
clang++-mp-4.0 -std=c++11 -stdlib=macports-libstdc++ future.cxx
--
   #include 
   #include 

  int main()
  {
  std::future f1 = std::async([](){ return 42; });
  f1.wait();
  std::cout << "Magic number is: " << f1.get() << std::endl;
  }
--

It does *not* work for OS versions prior to El Capitan with the error:
--
Undefined symbols for architecture x86_64:
  "std::__once_call", referenced from:
  void std::call_once ()>*, bool*),
std::__future_base::_State_baseV2*,
std::function ()>*,
bool*>(std::once_flag&, void
(std::__future_base::_State_baseV2::*&&)(std::function ()>*, bool*),
std::__future_base::_State_baseV2*&&,
std::function ()>*&&, bool*&&) in
future-b039c9.o
--
  clang++-mp-4.0 -std=c++11 -stdlib=macports-libstdc++ -femulated-tls future.cxx
--
compiles fine but experiences a segmentation fault at runtime.

When I build GCC with --disable-tls, everything works on all platforms.

I realize that -stdlib=macports-libstdc++ is a highly unsupported
configuration, but --disable-tls would not seem to affect newer OSs.

Does anyone have any insight into this?
Does anyone have any objections to adding --disable-tls?

Thanks,
Marcus

rsync server out of date?

[Marcus Calhoun-Lopez]

I just ran `port sync`, but the ports are several days behind the GitHub 
repository.
Is anyone else having this problem?

-Marcus

Re: cxx11-1.1 & gcc

[Marcus Calhoun-Lopez]

My current plan for octave is essentially:
PortGroup   compilers  1.0
PortGroup   cxx11 1.1
compiler.blacklist-delete *gcc*
compilers.setup ...

This seems reasonable for the probably small number of ports that are isolated 
enough
to use GCC even when configure.cxx_stdlib is libc++.

So far, I haven’t run into any problems, but the buildbots have not had a 
chance to prove
me wrong yet.

Thanks,
Marcus

> On Feb 23, 2017, at 3:26 AM, Mojca Miklavec  wrote:
> 
> Dear Marcus,
> 
> After you did the changes in cmake 1.1 I discovered the following in your 
> port:
> 
> 
> # see 
> https://lists.gnu.org/archive/html/octave-maintainers/2016-05/msg00286.html
> #PortGroup   cxx11 1.0
> # Octave requires c++-11 but can not use cxx11 PortGroup because Octave also
> #requires fortran from gcc
> # Compilers supporting C++11 are GCC >= 4.6 and clang >= 3.3.
> # See https://trac.macports.org/ticket/53044 for restricting clang
> versions further
> PortGroup compiler_blacklist_versions 1.0
> compiler.blacklist-append   {*gcc-3*} {*gcc-4.[0-6]} {clang < 700} cc
> 
> ... followed by some way more complex code.
> 
> Since the number of ports using the new cxx11-1.0 PG is still pretty
> low and thus the changes would not affect too many ports (and
> hopefully not break any of them), I was wondering if it would make
> sense to try incorporating some of code from octave to that PortGroup,
> so that ports that need Fortran could just include the PortGroup and
> be done with it.
> 
> What I mean is adding a slightly less aggressive blacklisting of gcc
> compilers and allow gcc >= 4.7 under some special circumstances.
> 
> I don't know if that's doable or reasonable, it's just a thought.
> 
> I'll keep testing your idea of linking against gcc's stdlib.
> 
> Mojca

Re: Feedback on clang change (#53194)

[Marcus Calhoun-Lopez]

> On Feb 1, 2017, at 2:37 PM, Mojca Miklavec  wrote:
> 
> So basically you need this to be able to compile binaries and
> libraries against the same stdlib, where you need gcc6 for one and
> clang for the other and the trick with D_GLIBCXX_USE_CXX11_ABI=0 is
> not sufficient?
The proposal is mostly about respecting the value of cxx_stdlib.
If cxx_stdlib is set to libstdc++ (the default prior to OS X Mavericks) and 
C++11 is required, the only options
are GCC or  clang with the proposed patch.
Since GCC doesn’t always interact well with the system libraries, that leaves 
the proposed patch.

Example:
Octave has a dependency on GraphicsMagick.
If cxx_stdlib is set to libstdc++, GraphicsMagick includes 
/usr/include/c++/4.2.1/string and links against /usr/lib/libstdc++.6.dylib.
So far, no problems.
Octave requires C++11 and and can not use GCC (it can but requires jumping 
through a few hoops).
That leaves clang using MacPorts libstdc++.
Even with the proposed patch, it would not work initially.
You get errors like
undefined symbols:
"Magick::Image::ping(std::__cxx11::basic_string const&)"
/usr/include/c++/4.2.1/string and /opt/local/include/gcc6/c++/string have 
different naming schemes since the GCC internal representation of strings (and 
lists) are different.
Prior to GCC 5.1, strings were Copy-On-Write, which is incompatible with 
the C++11 standard.
Setting _GLIBCXX_USE_CXX11_ABI=0 forces /opt/local/include/gcc6/c++/string 
to use the old (technically C++11 incompatible) Copy-On-Write
representation of strings that is compatible with 
/usr/include/c++/4.2.1/string and /usr/lib/libstdc++.6.dylib.

I am not sure if that answers your question or is even understandable.

>> My point of reference: 
>> https://gcc.gnu.org/onlinedocs/libstdc%2B%2B/manual/using_dual_abi.html
>> The following code is what I wrote to test various combinations.
>> The -D_GLIBCXX_USE_CXX11_ABI=0 forces the new libstdc++ string and list 
>> implementations to be compatible with the old libstdc++ string and list 
>> implementations.
>> 
>> main.cxx:
>>#include "f1.hxx"
>>int main() { f1("Hi There"); }
>> 
>> f1.hxx:
>>#include 
>>void f1(const std::string& string);
>> 
>> f1.cxx
>>#include "f1.hxx"
>>#include 
>>void f1(const std::string& string) { std::cout << string << "\n"; }
>> 
>> /opt/local/bin/g++-mp-6 -c -D_GLIBCXX_USE_CXX11_ABI=0 f1.cxx
>> /usr/bin/clang++ -c -stdlib=libstdc++ -std=c++11 main.cxx
>> /usr/bin/clang++ -stdlib=libstdc++ *.o
>> ./a.out
>> /opt/local/bin/g++-mp-6 *.o
>> ./a.out
> 
> So just to make sure: is this orthogonal to the current discussion?
> That is: assuming you use
>clang++ -stdlib=macports-libstdc++ ...
Sorry, that was not clear.
This is *not* orthogonal.
Substitute “clang++ -stdlib=macports-libstdc++” for “/opt/local/bin/g++-mp-6” 
and the point remains.

> What is then the situation with respect to compatibility? Does that
> mean that binaries compiled with "clang++ -stdlib=macports-libstdc++"
> will (only) be compatible with other libraries built with gcc6 (or
> with the same method), but incompatible with binaries built against
> libc++ and /usr/lib/libstdc++.dylib?
As I understand the situation:
“clang++ -stdlib=macports-libstdc++” and
“/opt/local/bin/g++-mp-6”
are compatible with each other but *not* with anything else.

“clang++ -stdlib=macports-libstdc++ -D_GLIBCXX_USE_CXX11_ABI=0,”
/opt/local/bin/g++-mp-6 -D_GLIBCXX_USE_CXX11_ABI=0,”  and
/usr/bin/clang++ -stdlib=libstdc++
are also compatible with each other but not with anything else.

>> When the patched clang is called, the header files of gcc6 are used and the 
>> libraries from libgcc are linked in.
> 
> But the libraries are only linked into the compiled binary, not into
> clang, right?
That is correct.
The clang compiler itself never uses anything from GCC.

> And the header files are only used when maports-libstc++ is requested, I 
> assume?
That is also correct.
The GCC header files are only included if maports-libstdc++ is requested.

> Are there any negative consequences if the user:
> - installs clang (with support for macports-libstdc++)
> - doesn't compile any binary against maports-libstc++
> - uninstals libgcc
> Would the compiler crash or stop working?
All binaries compiled in this manner would be unaffected.
“clang++ -stdlib=libstdc++” and “clang++ -stdlib=libc++” would continue to work 
just fine.
“clang -stdlib=maports-libstdc++” would attempt to use the clang header files 
while linking against /usr/lib/libstdc++.6.dylib.
In theory, we could add some checks to in the clang patch, but I did not bother 
since gcc6 was a library dependency.

> With all that, having one special subport of just the latest clang
> (with some special name) that would perhaps even compile against
> libstdc++ by default doesn't sound such a bad idea either.

In 

Re: Qt5 on 10.7?

[Marcus Calhoun-Lopez]

You are not missing anything.
That was my mistake.
I will fix it as soon as I get the chance.
Sorry about that.

-Marcus

> On Jan 25, 2017, at 1:39 PM, Michael Dickens  wrote:
> 
> When using Mac OS X 10.7 and I try to get info on any port that uses the
> Qt5 PortGroup, I get the error that "Port qt56-qtbase not found".  A
> little searching finds that in the qt5-1.0 PortGroup, the proc
> "qt5.get_default_name" returns "qt56" for this OS version, which is then
> used as the base for the Qt5 ports: qt56-qtbase, etc The issue is
> that there are no qt56* ports -- "port search qt56" returns "No match
> for qt56 found".  If I insert "set qt_name qt5" -before- the qt5
> PortGroup is called, then everything works as expected, and I can
> install qt5-qtbase (5.6.2) and it works, plus or minus. Am I missing
> something? - MLD

Re: Handling C++11

[Marcus Calhoun-Lopez]

> On Jan 19, 2017, at 2:04 PM, Chris Jones  wrote:
> 
> I don't think we should, under any circumstances, but making the use of gcc 
> to build c++ ports a standard practise.

Just to be clear, the proposal is not to use gcc but to use clang with 
libstdc++ and *only* on systems where it has been requested.
Your point, either way, remains valid.
However, I would argue that the proposal is not about changing any existing 
practices.
libc++ and clang would still, by far, be the best choices.
LibcxxOnOlderSystems would still be the recommendation for older system.
The proposal is only about attempting to respect what the user has requested.

-Marcus

Re: Handling C++11

[Marcus Calhoun-Lopez]

> On Jan 17, 2017, at 1:08 PM, Ken Cunningham  
> wrote:
> 
> Anyway, point of all this is that I'm extremely impressed with the way
> the macports devs and Jeremy have enabled libc++ / modern llvm-clang
> on 10.6 and 10.7, and would hate to see us move very far away from
> that or overly confuse the issue. The current situation is just
> fantastic for 10.6/10.7, and uses largely the same portfile structure
> as 10.9+, minimizing hassles for port authors.

You bring up some important considerations (including not overly confusing the 
issue).
Just to be clear, however, for those people using libc++, nothing would change, 
even using the new PortGroup.

-Marcus

Re: Handling C++11

[Marcus Calhoun-Lopez]

> Apple's lawyers don't think so, so you cannot redistribute anything combining 
> Apple libraries with it. (Since you can't avoid libSystem, this means you 
> cannot redistribute binaries.)
> 
> It's not a question of what makes sense to you, it's not a question of what 
> would be convenient. Apple called the shots and we are forced to adapt.

Please understand, I was not trying to argue the point.
I just had no idea that mixing libSystem with libstdc++ made a binary 
non-distributable.
Thank you for clarifying.

This reveals a bigger problem than just my proposal.
I do not think our buidbot recognizes this fact.
For example, the binary version of the gcc port we distribute mixes libSystem 
and libstdc++.

otool -L /opt/local/lib/gcc6/i386/libasan.3.dylib
/opt/local/lib/gcc6/i386/libasan.3.dylib:
/opt/local/lib/gcc6/i386/libasan.3.dylib (compatibility version 4.0.0, 
current version 4.0.0)
/opt/local/lib/gcc6/i386/libstdc++.6.dylib (compatibility version 
7.0.0, current version 7.22.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 1238.0.0)
/opt/local/lib/gcc6/libgcc_s.1.dylib (compatibility version 1.0.0, 
current version 1.0.0)

-Marcus

Handling C++11

[Marcus Calhoun-Lopez]

At the risk of rehashing a closed topic, I would like to propose a new way of 
handling C++11 (especially on older systems).
I have opened three tickets that I hope, together, would solve some of the 
issues raised previously.

[1] https://trac.macports.org/ticket/53194
[2] https://trac.macports.org/ticket/53330
[3] https://trac.macports.org/ticket/53329

I still may not 100% understand libstdc++ vs libc++ vs GCC 5.1 libstdc++, so 
any suggestions and feedback would be most welcome.

For my own purposes, I would like to both support Octave and Qt on older 
systems and have the buildbots build them.
Both packages require C++11.
Qt seems to very much require clang to properly interact with the system 
libraries.

Thank you,
Marcus