Updating CMake to 3.20?

[Michael Dickens]

Hi MP folks - CMake has recently released the 3.20 branch, but is for the 
moment also pushing fixes to the 3.19 branch. I updated the port to 3.19.8 
yesterday. The 3.20 branch is the future of CMake, and I'm confident introduces 
new features that folks will want to use; it likely deprecates some older 
features as well, some of which might be in use by current ports that use CMake 
for building -- though to be honest I don't know this for a fact, it's just the 
way things have been in the past and so why would it be any different this time 
around? I will do some testing on the current 3.20 release to make sure it 
works with the ports that I use -- mostly Volk, UHD, and GNU Radio related -- 
and if so then I'll propose updating CMake accordingly. I'm wondering what 
folks here think ... have you tried this new CMake? Is it compatible with MP? 
With your personal project(s)? Any known worries or incompatibilities? - MLD

Re: what say we just use MacOSX.sdk preferentially on BigSur and up?

[Michael Dickens]

+1 from me to use just MacOSX.sdk !

On Thu, Dec 31, 2020, at 11:56 AM, Ken Cunningham wrote:
> So I will make another push for this, before we get hundreds of ports 
> built with incorrect burned-in SDKs that make a total mess for us to 
> manage.
> 
> 
> What is different now is that almost all current configure software 
> does a test-compile and run rather than look for a specific header or 
> function to be defined, and if they don’t, they will need to.
> 
> 
> The rapidly-changing SDK names make anything other than this a total mess.
> 
> IMHO, it is not a good idea, or reasonable, to expect every single 
> piece of software (perl, python, ruby, gcc, etc, etc) to come up with 
> their own, probably broken method of sorting this out.
> 
> All current MacOS users are using an Xcode that defaults to MacOSX.sdk anyway.
> 
> We would have no more need to default to forcing users to use an older 
> Xcode version on many platforms that can run a newer version.
> 
> It’s just the plain old right thing to do, and that is where Apple and 
> everyone else is headed.
> 
> 
> Ken

Boost: what to do about it?

[Michael Dickens]

In MacPorts, "boost" is currently at 1.71.0. There are traditionally 3 Boost 
releases per year: late April, mid August, and early December. The current 
release of 1.75.0 was on December 11, 2020 < 
https://www.boost.org/users/history/version_1_75_0.html >.

Boost is a challenging port to get updated. The API changes regularly which 
breaks backwards compatibility. It takes time even for actively-in-development 
ports to get working with these releases; and older ports that are not actively 
in development will just fail eventually because the updated Boost API is so 
different. We can't just update the "boost" port because it breaks other ports; 
reliably; potentially for weeks if not months until fixes are in place. Some 
ports will of course work without modification; but many will not. Some of 
those ports are not trivially updated to work with newer Boost, whether by us 
directly or via upstream fixes. These reasons are why Boost is stuck where it 
is for such a long time.

Prior PRs have failed because too many boost-dependent ports could not be 
updated, and it would take too much aggregate time to do all of this work -- 
and so some of the ports updated in the PR get stale & need to be rebased, 
which takes even more time ... just not enough time in the day / week / month 
to get all of this done!

I don't know what the ideal solution here is, hence this email to start a 
discussion. What I do know is that -something- has to change, since MacPorts 
can't keep up with current Boost releases in the current way we handle the 
Boost ports ("boost" and "boost169").

The best solution I've been able to come up with is to make new boostXYZ ports 
that are installable in parallel: boost169 already exists, as noted; I don't 
have it installed yet, but it's on my list to do so, to try to figure out the 
right way to do such parallel installs. We would then move the current 
"port:boost" to "port:boost171" and change the dependency for all ports that 
depend on it. Then, we can add in Boost 1.72 / 73 / 74 / 75, and any port that 
can be updated to newer Boost has the option to be updated; and, also, all 
future Boost releases will be simple to add in as a new port.

The primary downside of just having boostXYZ is keeping those older Boost 
versions building on newer macOS and newer compilers ... but, this is almost 
always challenging anyway, so I don't see this is a new issue.

What does the MacPorts-hive think here? I should have some time in the coming 
month or so to do this work; I'd like to have some general agreement as to what 
the work should be. - MLD

Re: llvm/clang/lldb -devel on Apple Silicon

[Michael Dickens]

Very cool! Does this Clang provide Fortran compiling yet? - MLD

On Tue, Nov 24, 2020, at 12:47 PM, Ken Cunningham wrote:
> So the latest build of llvm etc did build through and install on Apple Silicon
> 
> That is a milestone of sorts I think.
> 
> This allows openmp, and the first alternative compiler to try for failed 
> builds.
> 
> I’ll move this into llvm/clang 11 soon, once I finish wrestling with 
> the github PG.
> 
> Best,
> 
> Ken

Re: Thanks for the poppler / gobject-introspection fixes

[Michael Dickens]

You're welcome! Although the level of my participation in MacPorts ebbs and 
flows, I always greatly value what MacPorts provides for me -- my work and 
hobbies -- and look to make things better when I can find the time to do so & 
where the issue aligns with my talents / expertise. Cheers! - MLD

On Thu, Oct 29, 2020, at 6:18 AM, Ruben Di Battista wrote:
>  
> 
> On Thu, 29 Oct 2020, 05:22 Joshua Root,  wrote:
>> Thanks so much Michael for fixing the gobject-introspection bugs that
>> were preventing poppler from building while an older version of itself
>> was installed. That has been the cause of a lot of grief for a long time.
>> 
>> - Josh

Re: Hardcoding Xcode.app

[Michael Dickens]

Beta Xcode is at "/Applications/Xcode-beta.app" ... so, no, we can't hard code 
that precisely. That said, it wouldn't be difficult to have this setting as a 
preference in a .conf file, if it isn't already. That way it -can- be changed 
for those of us who regularly run beta software. - MLD

On Fri, Oct 9, 2020, at 3:58 PM, Christopher Chavez wrote:
> Can MacPorts hardcode references to Xcode.app, by assuming it is at 
> /Applications/Xcode.app (as when installed from the App Store), and/or 
> that it will remain wherever it was found and won't ever be 
> moved/deleted?
> 
> I would think the answer is "no": it is outside of MacPorts' control, 
> and some users have reason to switch between multiple installed Xcode 
> versions.
> 
> See https://trac.macports.org/ticket/58378#comment:7 . I think I have 
> come across other instances of this issue, but can't remember where.
> 
> 
> Christopher A. Chavez
>

Re: Apple ARM binary codesign issue

[Michael Dickens]

We're in luck. The latest Xcode 12.2 beta 2 seems to work with MacPorts without 
modification on either end. Whew! Now back to getting ports installed and fixed 
on ARM64! - MLD

On Fri, Sep 25, 2020, at 9:05 PM, Ryan Schmidt wrote:
> 
> 
> On Sep 25, 2020, at 10:31, Michael Dickens wrote:
> 
> > Install scripts are calling ‘install -s’ which in turn calls ‘strip’.
> > 
> > After fighting with my hacks for a while I do think the best option is the 
> > very-final-destroot as mentioned.
> > 
> > I’d appreciate any advice on where and how to add this in MacPorts 
> > installed files ... I’m not an expert in macports-base.
> 
> You would do it in proc portdestroot::destroot_finish in 
> src/port1.0/portdestroot.tcl.
> 
> I am still hopeful that we will need to make no changes to MacPorts 
> base or ports for this, and that Apple will fix their tools to work 
> properly again.
> 
> 
>

Re: Apple ARM binary codesign issue

[Michael Dickens]

Install scripts are calling ‘install -s’ which in turn calls ‘strip’.

After fighting with my hacks for a while I do think the best option is the 
very-final-destroot as mentioned.

I’d appreciate any advice on where and how to add this in MacPorts installed 
files ... I’m not an expert in macports-base.

Thx! - MLD 

On Fri, Sep 25, 2020, at 11:04 AM, Ken Cunningham wrote:
> 
> 
> > On Sep 25, 2020, at 7:55 AM, Michael Dickens  wrote:
> > 
> > Also: many build scripts call /usr/bin/strip directly or xcrun strip ... so 
> > that would bypass our MP efforts ... we'd have to patch up all of those 
> > ports to coerce them into running the MP strip ... that seems like a lot of 
> > work! Maybe there's a way around that? I'm not thinking of it off the top 
> > of my head. - MLD
> > 
> 
> Yeah, build scripts should not be calling /usr/bin/strip directly, and 
> in the end, then will all eventually need fixing. I often have to fix 
> things like that to make builds use the newer cctools on older systems.
> 
> I haven’t explored what "xcrun —find” does re: finding our cctools port 
> as yet...
> 
> I actually thought Josh’s (or was it your) idea to run a codesign fixup 
> step in base after the build was done sounded like the best idea to me, 
> but there are probably ports that do something funky in “post-destroot” 
> or somewhere that would show up warts.
> 
> Ken
> 
>

Re: Apple ARM binary codesign issue

[Michael Dickens]

Also: many build scripts call /usr/bin/strip directly or xcrun strip ... so 
that would bypass our MP efforts ... we'd have to patch up all of those ports 
to coerce them into running the MP strip ... that seems like a lot of work! 
Maybe there's a way around that? I'm not thinking of it off the top of my head. 
- MLD

On Fri, Sep 25, 2020, at 10:52 AM, Michael Dickens wrote:
> Can't do both "exec" and then other stuff. If we remove the "exec" and 
> then add in the codesign ... maybe ... I'll test that once I get this 
> version working.
> 
> Yes: We need to fix cctools to install "install_name_tool" ... not sure 
> why it's not there.
> 
> On Fri, Sep 25, 2020, at 10:46 AM, Ken Cunningham wrote:
> > Would it not be easier to add that codesign line in the existing script 
> > that the cctools port writes to wrap those tools for the +xcode variant 
> > of cctools, perhaps?
> > 
> > (well, NB cctools is not presently wrapping install_name_tool for the 
> > +xcode variant, but that looks like an oversight trivially fixed).
> > 
> > K

Re: Apple ARM binary codesign issue

[Michael Dickens]

Let's try this again from my MP email so that it gets to lists ... sorry for 
duplicate emails!

I've finally gotten to the point of working out a hack solution.

One can -not- modify '/usr/bin' without a lot of effort. But, one can modify 
'/Applications/Xcode[-beta].app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin'
 ... and yes I know this is outside the scope of what MP does or is (likely) 
willing to do. As noted: This is a hack to prove that it works.

In 
'/Applications/Xcode[-beta].app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin'
 I move the target executables from 'foo' to 'foo_orig', then create a script 
'foo' that first calls 'foo_orig ${@}' then 'codesign' to update the signature 
on the binary. The executables in '/usr/bin' just call those in 
'/Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin',
 so my script is treated as a system provided executable for 'foo'. Initial 
testing looks positive, regardless of how hacky this is.

Question: which executables am I targeting here? I think 'strip', 'lipo', and 
'install_name_tool' are the obvious ones. is that all? Any others that need 
this wrapping? - MLD

Re: Apple ARM binary codesign issue

[Michael Dickens]

I have macOS 11.0beta7 installed : check!

Compare / contrast ARM Mac versus MacBook Pro 16 : check!

I have Xcode 12.2 beta installed : check!

I've removed "/Library/Developer/CommandLineTools" : check!

I hope that Apple fixes their toolchain to work without such intervention : 
check!

Do you know that best way we can complain to Apple to fix the toolchain?

Still doesn't work for me ... those specific files are almost the only ones 
that just don't respond to codesign. I'll try reinstalling from scratch ... 
maybe ports built with Xcode 12.0 don't entirely work with those built using 
12.2beta? H 

Thx! - MLD

On Tue, Sep 22, 2020, at 2:58 PM, Ryan Schmidt wrote:
> 
> 
> On Sep 22, 2020, at 13:29, Michael Dickens wrote:
> 
> > % codesign -v - --ignore-resources 
> > /opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8
> > /opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: 
> > invalid signature (code or signature have been modified)
> > % sudo codesign -s - 
> > --preserve-metadata=identifier,entitlements,flags,runtime -f 
> > /opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8
> > /opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: 
> > replacing existing signature
> > /opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: 
> > the codesign_allocate helper tool cannot be found or used
> > % which codesign
> > /usr/bin/codesign
> > % which codesign_allocate
> > /usr/bin/codesign_allocate
> > 
> 
> You need Xcode 12.2 beta, which you probably have, but also make sure 
> that you don't have old command line tools installed. I don't think the 
> Xcode 12.0 beta command line tools are compatible, and there isn't an 
> Xcode 12.2 beta command line tools yet. Delete 
> /Library/Developer/CommandLineTools.
> 
> 
> % codesign -v - 
> mp/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8
> mp/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: 
> invalid signature (code or signature have been modified)
> In architecture: arm64
> % codesign -s - 
> --preserve-metadata=identifier,entitlements,flags,runtime -f 
> mp/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8
> mp/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: 
> replacing existing signature
> ...
> % codesign -v - 
> mp/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8
> mp/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: 
> valid on disk
> mp/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: 
> satisfies its Designated Requirement
> %
> 
> 
> > Mentioned as possible fixes were: (1) inserting MP strip and 
> > install_name_tool wrappers that sign the binary if the signature is broken; 
> > or (2) a new step in destroot_finish .
> 
> I hope that Apple fixes their toolchain to work without such intervention.
> 
>

Apple ARM binary codesign issue

[Michael Dickens]

There has been some discussion about the recent change Apple made for macOS 
11.0beta7 for ARM Mac only (-not- Intel Mac at this time); we in MP-land had 
some on this PR < https://github.com/macports/macports-ports/pull/8328 >. As 
pointed out, a better venue for discussion would be these lists.

The brief summary is that Apple is instituting code signing for all binaries 
during linking as noted here < 
https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11-universal-apps-beta-release-notes#Updates-in-macOS-Big-Sur-11-Universal-Apps-Beta-7
 >. The signing is as-hoc and done automatically; it is invalidated if one 
modifies the binary in any way ... for example using "strip", or 
"install_name_tool" to change the name of a required library, or even the 
self-ID name.

Many MacPorts installs use various post-linking means to tweak the resulting 
binary, and hence these are not currently usable under macOS 11.0beta7 or more 
recent on ARM Mac only; again: this change is NOT for Intel Mac -- at least not 
at this time.

One can test whether the signing is valid via the command: "codesign -v FILE" ; 
according to Apple one should use "codesign -v - --ignore-resources FILE" 
to be more verbose as well as look at just the non-resource binary. Both work 
in my testing.

In my initial testing, some of the binaries can be made to work via the command 
"[sudo] codesign -s - --preserve-metadata=identifier,entitlements,flags,runtime 
-f FILE" ... but, not all! For example:
{{{
% codesign -v - --ignore-resources 
/opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8
/opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: 
invalid signature (code or signature have been modified)
% sudo codesign -s - --preserve-metadata=identifier,entitlements,flags,runtime 
-f /opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8
/opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: 
replacing existing signature
/opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: the 
codesign_allocate helper tool cannot be found or used
% which codesign
/usr/bin/codesign
% which codesign_allocate
/usr/bin/codesign_allocate
}}}

So in this case, "codesign_allocate" cannot be used for some non-obvious reason 
(as it clearly is in the PATH and works for some other codesign efforts). The 
same holds true for some of the Python libraries and some of the primary 
executables -- but, not all!

Mentioned as possible fixes were: (1) inserting MP strip and install_name_tool 
wrappers that sign the binary if the signature is broken; or (2) a new step in 
destroot_finish .

Let's pick up the discussion here, and try to work out a fix in short order. 
For those of us trying to do anything within MacPorts using ARM Mac, this new 
feature is causing significant issues & needs to be dealt with so that we can 
get back to real work instead of fighting macOS::codesign .

Cheers! - MLD

Re: [macports-ports] branch master updated: cmake: update to 3.17.1

[Michael Dickens]

Nice catch! Let me go about fixing that tpyo up! (yes, that was intentional ...)

On Tue, Apr 14, 2020, at 11:09 AM, Frank Schima wrote:
> Hi Michael,
> 
> 
>> On Apr 14, 2020, at 8:37 AM, Michael Dickens  wrote:
>> 
>> Michael Dickens (michaelld) pushed a commit to branch master
in repository macports-ports.

>> 
>> https://github.com/macports/macports-ports/commit/a2b35ff01110fe89e56a898876b65863f26b0073

>> The following commit(s) were added to refs/heads/master by this push:
>>  new a2b35ff  cmake: update to 3.17.1
>> a2b35ff is described below

>> commit a2b35ff01110fe89e56a898876b65863f26b0073
>> Author: Michael Dickens 
AuthorDate: Tue Apr 14 10:37:01 2020 -0400

>> cmake: update to 3.17.1
>> 
>> Deprecate cmake-devel: cmake is updated regularly enough to not warrant 
>> needing this port.
>> ---
 devel/cmake/Portfile   | 505 ++---
 .../patch-CMakeFindFrameworks.cmake.devel.diff |  11 -
 .../files/patch-Modules-noArchCheck.devel.diff |  72 ---
 ...patch-Source_Modules_FindLibUV.cmake.devel.diff |  13 -
 .../files/patch-cmake-leopard-tiger.devel.diff | 119 -
 .../files/patch-fix-clock_gettime-test.devel.diff  |  15 -
 .../files/patch-fix-system-prefix-path.devel.diff  |  75 ---
 .../files/patch-fix_cxx14_17_checks.devel.diff |  63 ---
 devel/cmake/files/patch-qt4gui.devel.diff  | 172 ---
 devel/cmake/files/patch-qt5gui.devel.diff  |  93 
 10 files changed, 243 insertions(+), 895 deletions(-)

>> diff --git a/devel/cmake/Portfile b/devel/cmake/Portfile
>> index 115e89b..50eb99a 100644
>> --- a/devel/cmake/Portfile
>> +++ b/devel/cmake/Portfile
>> @@ -6,7 +6,7 @@ PortGroup   xcodeversion 1.0
>>  PortGroup   gitlab 1.0
 PortGroup   legacysupport 1.1
 
>> -# Cmake is a depedency of clang
>> +# CMake is a depedency of clang
>> 
> 
> “dependency” is still spelled incorrectly here. :)
> 
>>  

Re: [MacPorts] #59505: Failed to upgrade from mariadb-10.2-10.2.25_0 to mariadb-10.2-10.2.27_0

[Michael Dickens]

Stealth update ... fixed just now in 
​https://trac.macports.org/changeset/4c9cf8ada448a44cf3964f67278f77c27b72a7c9/macports-ports

On Wed, Nov 6, 2019, at 7:41 AM, Gregg Green wrote:
> Getting this error on macOS 10.13.6
> 
> port install mariadb-10.2
> --->  Computing dependencies for mariadb-10.2
> --->  Fetching archive for mariadb-10.2
> --->  Attempting to fetch mariadb-10.2-10.2.28_1.darwin_17.x86_64.tbz2 
> from https://packages.macports.org/mariadb-10.2
> --->  Attempting to fetch mariadb-10.2-10.2.28_1.darwin_17.x86_64.tbz2 
> from http://aus.us.packages.macports.org/macports/packages/mariadb-10.2
> --->  Attempting to fetch mariadb-10.2-10.2.28_1.darwin_17.x86_64.tbz2 
> from 
> http://ywg.ca.packages.macports.org/mirror/macports/packages/mariadb-10.2
> --->  Verifying checksums for mariadb-10.2
> Error: Checksum (rmd160) mismatch for server-10.2.28.tar.gz
> Error: Checksum (sha256) mismatch for server-10.2.28.tar.gz
> Error: Checksum (size) mismatch for server-10.2.28.tar.gz
> Error: Failed to checksum mariadb-10.2: Unable to verify file checksums
> Error: See 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_databases_mariadb-10.2/mariadb-10.2/main.log
>  
> for details.
> Error: Follow https://guide.macports.org/#project.tickets to report a 
> bug.
> Error: Processing of port mariadb-10.2 failed
> 
> 
> On 11/5/19 4:11 PM, MacPorts wrote:
> > #59505: Failed to upgrade from mariadb-10.2-10.2.25_0 to 
> > mariadb-10.2-10.2.27_0
> > ---+---
> >Reporter:  jvmyers   |  Owner:  michaelld
> >Type:  defect| Status:  closed
> >Priority:  Normal|  Milestone:
> >   Component:  ports |Version:
> > Resolution:  fixed |   Keywords:
> >Port:  mariadb-10.2  |
> > ---+---
> >
> > Comment (by michaelld):
> >
> >   @GreggGreen : Please update your ports tree again. There's a subsequent
> >   commit (after the update to 10.2.28) that should fix this issue. Please
> >   "sudo port clean mariadb-10.2" before trying again ...
> >
>

Advice for Boost CMake scripts

[Michael Dickens]

We're working on updating Boost to 1.70.0 < 
https://github.com/macports/macports-ports/pull/4243 > ... we'd value others 
participating, BTW! Thus far many ports work out of the box with it (current 
Boost in MacPorts is 1.66.0, so there are some significant bug fixes and API 
changes to deal with); many of the ports that depend on Boost just need small 
tweaks to get them working; a few are above our amount of effort available & we 
hope upstream or someone so motivated fixes them.  ... but that's not what this 
email is about.

I'm looking for advice on how to move forward with Boost 1.70.0's CMake find 
scripts: do we just not install them? Or do we patch them via what upstream has 
already done? Or do we just wait for 1.70.1 -- which will contain those fixes 
-- to be released & skip 1.70.0 entirely (and, ban it from ports in which we 
easily can do so)?

Here's the scoop, for those curious to know:

One change with -huge- impact that is installed by default by Boost 1.70.0 is 
CMake "find" scripts ... which as it turns out were -not- ready for release 
just yet. Boost folks already have a fix upstream, and I sincerely hope they 
come out with 1.70.1 with these fixes. Virtually -all- projects using CMake to 
find Boost via the Boost 1.70.0-provided CMake find scripts will fail to 
configure or build due to issues with these scripts.

CMake has for years provided a "FindBoost.cmake" script that has been 
reasonably robust, and they still are. This script works very robustly within 
MacPorts, because we abide by the common ABI naming variants that it checks for.

Luckily, Boost 1.70.0 provides an option to not install its CMake find scripts 
... so, at least within MacPorts we can control whether these scripts are not 
installed and thus are not used, at least for 1.70.0. To Boost's credit, their 
fixed-up CMake find scripts are much more robust than the single one provided 
by CMake, and can be installed in parallel with other future Boost CMake find 
scripts (because of their naming, over which we have no control, but which 
include the whole version number).

Hence my looking for advice. Thanks in advance for your thoughts! - MLD

Re: Errors when changing cmake build directory

[Michael Dickens]

Just remember that "${destroot}" will not exist until the "destroot" phase 
unless it is created in the Portfile script. If you need a different build 
directory than that provided by the CMake PG, then you can in the Portfile 
create some other directory & my advice would be to place it in the top level 
"${worksrcpath}" directory -- which is where the "build" directory is placed. 
Not sure why one would need this, but maybe there's a use-case I'm not 
imagining. Good luck! - MLD

On Thu, May 2, 2019, at 3:20 PM, Ao Liu wrote:
> Um. Good to know that. 
> 
> I think what I would like to do can be achieved by smartly using ${destroot} 
> to deploy a new build dir and move the files to where I would like. In this 
> case the build happens in the work dir and will eventually end up in where I 
> want it to be.
> 
> As I suggested in a recent ticket - it would be nice for the website to 
> explain the ${destroot} variable in more details. Helps the developer to 
> build powerful stuff. 
> 
> Thanks for the replies folks!
> Ao

Re: Errors when changing cmake build directory

[Michael Dickens]

Hi Fred - My thoughts follow. This will likely be my only reply to your post or 
reply here since it's heading toward being off-topic & honestly comes down much 
more to personal preference than any technical requirement; it's more along the 
lines of a "culture war" such as "Mac versus PC", "iPhone versus Android" and 
the like. Each side has benefits and drawbacks; neither side is entirely in the 
right nor in the wrong. There is very little point in flaming such wars.

(1) CMake and in-source versus out-of-source:

In my opinion you're not correct: CMake itself is build-location agnostic; it 
does not default to in-source builds. Individual projects may choose to provide 
just in-source building, but in my experience the vast majority of projects 
that use CMake for building can be built in-source or out-of-source. 

When one issues the "cmake" command, the final argument is the directory 
containing the top-level CMakeLists.txt file in the source to be built; this 
directory can be relative (e.g., ".", or ".."), or absolute (e.g., 
"/path/to/top/level/cmakelist_txt/dir/"). Modern and recent CMake itself is 
agnostic as to whether one builds in-source or out-of-source; such CMake has no 
default either way, whether explicit or implicit. NOTE: I do think that -very 
old- CMake maybe did require in-source builds, but we're talking version 1 or 
maybe early version 2 -- many years ago!

In my many years of using CMake (since sometime in mid-version 2), CMake has 
worked for both in-source and out-of-source builds quite robustly; the CMake 
scripting required to make it work both ways is nominally different than 
requiring in-source builds. Some projects wrote their original CMake scripts 
with in-source in mind, and have never bothered to update their CMake scripts 
to allow for out-of-source builds. The vast majority of projects that I've ever 
heard of or experienced that use CMake work with out-of-source builds, whether 
because the CMake scripts were originally written in the generic build location 
style, or because they were fixed to allow building either way.

(2) cmake PG settings:

The default cmake 1.1 PG settings are for out-of-source builds: yes! But, one 
can in any individual Portfile change this setting quite easily or just use the 
cmake 1.0 PG, which defaults to in-source builds (with the option of doing 
out-of-source builds if set specifically in the Portfile using this PG). v1.1 
is more robust overall, but v1.0 is probably plenty sufficient for many ports.

(3) benefit of cmake out-of-source builds:

The benefit of out-of-source builds is negligible in the MP environment: true 
if you're just an end-user! I tend to believe that most MP users just want MP 
to work, whether compiling from source or installing via a pre-built archive. 
CMake out-of-source builds are meaningless from this perspective.

That said, to get ports to the point where they install and work robustly, the 
out-of-source build is a convenience for developers who are doing the work to 
get ports to this point. I have scripts that allow me to manipulate project 
source code as provided via "port work", e.g., to create a top-level temporary 
GIT repo so that I can easily get "diff"s to what's changed & then create a 
patch for those changes; I can tweak the build scripts and actual code to be 
compiled until it works in the ways I deem robust. Having an out-of-source 
build means I can just "rm -rf" the build directory and restart the build from 
scratch. One can, of course, "make clean" whether building in-source or 
out-of-source but that may or not do the trick depending on how well the CMake 
scripts keep track of build or modified files; "rm -rf" is -very- reliable at 
cleaning the build!

---
Summary: CMake out-of-source builds, at least in my opinion and experience, are 
not difficult to have well implemented from the project developer's 
perspective, and they benefit us developers trying to make ports as robust as 
possible. I wouldn't want it any other way!

Cheers! - MLD

On Thu, May 2, 2019, at 3:00 PM, Fred Wright wrote:
> But note that CMake's own default is *not* to build out-of-source (with 
> extra steps required when you want to), and not all projects build 
> correctly out-of-source.  So the PG default behavior is inconsistent with 
> CMake itself, as well as just plain not working in some cases, and the 
> poor discoverability of the option to change that (as well as the change 
> in the default from 1.0) makes that default even more undesirable.
> 
> Also note that the benefit of out-of-source builds is negligible in the 
> MacPorts environment, anyway.
> 
> Fred Wright

SWIG 4.0.0 Released & Query

[Michael Dickens]

Hi MacPorts folks - SWIG 4.0.0 has been released after much ado < 
https://sourceforge.net/p/swig/news/2019/04/swig-400-released/ >. I'm positive 
that this release fixes a bunch of bugs from the prior 3.0.12 release, as well 
as adds a bunch of new useful features! But also as with any release there are 
probably bugs we don't yet really know about.

For those who don't know: SWIG creates a compiled interface between languages, 
for example from C++ to Python; hence, testing and verification are 2 parts: 
the build (e.g., compiled C++ / Python interface), and the binary (e.g., 
importing the compiled interface into Python). Testing dependent ports for the 
former (the build) is pretty straight forward, something our CI can handle for 
PRs once the new SWIG4 is in place. That said, there are some 190 ports that 
depend on the SWIG subports, which makes testing the latter (loading the 
compiled SWIG into the target language) challenging to verify.

Given the unknowns of how well SWIG4 will work with current ports and the sheer 
number of ports that depend on the various SWIG subports, I'm inclined to 
create a "SWIG4" port (and subports) that somehow -do not- conflict with SWIG 
(3; and subports), so that projects can still use the current SWIG (3; and 
subports, bugs and all) but have a migration path forward to the new SWIG4. 
SWIG (3) would no longer be maintained except critical bug fixes (if that); all 
future maintenance would be for SWIG4, and we'd create a ticket encouraging 
port maintainers to move their ports to SWIG4 if that's reasonably possible. 
Each port maintainer could then test / verify / fix their ports, individually 
and separately and in whatever time they need; there would be no real pressure 
to update to SWIG4 so long as SWIG (3) still builds.

Thanks in advance for your thoughts and advice on how to proceed here! - MLD

Re: base release to pick up new compiler selection options ?

[Michael Dickens]

Somehow I missed this commit ... after a quick review: YES; nicely done Marcus! 
I'll echo Chris' question: can someone comment as to when the next MP release 
will be so that we can start using this feature? Thx! - MLD

On Thu, Apr 18, 2019, at 5:20 AM, Chris Jones wrote:
> Hi,
> 
> I would like to be able to use the more fine grained compiler selection 
> implementated in
> 
> https://github.com/macports/macports-base/pull/88
> 
> but as this is not yet in a released version of base, no ports can yet 
> use it. Are there any plans to make a new release any time soon, to 
> enable use of new features like this ?
> 
> cheers Chris
>

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

[Michael Dickens]

Somehow those ports installed on my 10.14 boot. I haven’t checked if they are 
just a big NOP nor if they actually try to do something not if they even 
import/work at all. I’ll check this afternoon. - MLD 

On Mon, Apr 15, 2019, at 12:38 PM, Marcus Calhoun-Lopez wrote:
> 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 \
> > size 22086
> > 
> > 
> > -python.versions 37
> > 
> > +python.versions 27 34 35 36 37
> > 
> > 
> > if {${name} ne ${subport}} {
> > depends_build-append \
> > 
> > 
> 
> 

Re: Query: variant +docs or +doc?

[Michael Dickens]

I'd hope that there's a way to robustly move from one variant to the other 
without the user having to engage with "port" to do so. I would hope that we 
can avoid forcing the user to explicitly deactivate one and activate the other 
variant.

I can think of a way to do this where we would end up with both variants for a 
while during the transition ... the end result might be a bit confusing to 
view/read when listing installed ports, but at least this way would avoid 
forcing the user to do anything more than update outdated ports.

We can add a variant that depends on another variant. Thus, for example, if we 
were moving from "+doc" to "+docs", we could do:
{{{
variant doc requires docs description "Deprecated variant; use 'docs' instead" 
{}

variant docs description ... { [actual stuff to do for this variant] }
}}}
thus if the port currently has +doc enabled then doing this technique should 
force +docs too. That said, this method would end up with "+doc +docs" for a 
while, which isn't desirable.

I don't know if, after say 6 months, we then remove the deprecated "+doc" 
whether any update will still contain the notation "+doc" or whether it would 
be removed. One can test this out easily, of course.

I'm sure that some of the MacPorts main developers know better than me the 
answers here. Hope this is useful! - MLD

On Sun, Apr 14, 2019, at 3:17 PM, Richard L. Hamilton wrote:
> How would that work with regard to "port upgrade" of installed ports?  
> Would (for those ports presently using the one chosen to be changed) 
> both be accepted for compatibility?  Or some other magic?  Or would 
> people end up having to explicitly deactivate the installed one, and 
> install the new version with suitably altered variant(s) requested?
> 
> Seems to me the latter would be a nuisance best avoided.

Query: variant +docs or +doc?

[Michael Dickens]

See < https://trac.macports.org/ticket/58338 > with title "lots-o-ports: decide 
on common variant name to build documentation: +docs or +doc".

There are approximately 128 ports that use +doc or +docs as the variant to 
build documentation. Of those, approximately 75 use +docs, while the rest -- 
approximately 53 ports -- use +doc.

[[I say "approximately" because I did a global search in the ports tree using a 
specific pattern ("variant doc " and "variant docs " with the extra space) as 
well as just {"variant doc" | grep docs}, the latter of which returns slightly 
different results (& I can think of lots of reasons why but the result are 
similar; hence "approximately ...).]]

Because we can individually set global default variants, one could choose to 
set both here to get documentation to build, but I'll agree with Blair that 
just setting one is preferable. Hence, it would not hurt to, as a group of 
developers the users of MacPorts, decide which variant name should be the 
sanctioned way to build documentation, and then tweak those non-conforming 
ports to use the correct variant name.

Please direct your thoughts to that ticket to keep everything easily in one 
place. This email is mostly to direct your attention to this specific ticket / 
topic. Thanks! - MLD

Re: Use ISO 8601 dates in Portfile comments

[Michael Dickens]

I'm all for moving to this ISO, if someone wants to do this work. I already do 
so in my ports for the version of most devel versions & some "release" versions 
&& for comments too. - MLD

On Mon, Apr 8, 2019, at 1:42 AM, Mojca Miklavec wrote:
> On Mon, 8 Apr 2019 at 07:35, Joshua Root wrote:
> >
> > ISO 8601 is a great compliant solution to recommend.
> >
> > Changing ambiguous dates to something unambiguous is a reasonable thing
> > to submit PRs for if you so desire.
> 
> Ambiguous dates can be verified with "git log".
> 
> But I would do a PR for everything anyway (and merge it after three
> days as nobody would complain :)
> 
> Mojca
>

Re: force specific Qt5 version install?

[Michael Dickens]

On Fri, Apr 5, 2019, at 6:33 PM, Ryan Schmidt wrote:
> I am slightly concerned about this. The MacPorts base version is 
> available to Portfiles, and Portfiles do occasionally need to do 
> different things depending on the MacPorts base version. For example, 
> the behavior of *.env options was changed a couple weeks ago, so until 
> we release MacPorts 2.6.0, Portfiles need to use e.g. configure.env one 
> way to support MacPorts 2.5.4 and earlier and a different way to 
> support MacPorts 2.5.99 and later. These ports will check `if {[vercmp 
> [macports_version] 2.5.99] >= 0}` to decide whether to use the new 
> method. Now it just so happens that vercmp thinks "2019-03-23" is 
> greater than "2.5.99" so it still works, and I don't immediately see a 
> way that your change to the version number causes a problem, but I just 
> wanted to point out that it has the potential to do so.

Interesting. I hadn't thought of setting the version as introducing potential 
issues & am happy I got lucky with my version choice! Would it be better from 
the MP internals perspective if I use "2.5.99-2019-03-23" or something similar 
(adding to the original setting)?

> You mentioned your "OSX 10.12 boot" above. Do you use this ports tree 
> with different OS versions? If so, you must regenerate the portindex 
> (or `sudo port sync`, which redownloads or regenerates the portindex) 
> every time you switch OS versions; the port index contains information 
> that is specific to the OS version for which it was generated.

Ah ha! I bet this is the issue. I use a common partition for the base and ports 
(and other) repos, and assumed that the PortIndex would be common across all 
OSs once set. Thank you for enlightening me! Now I'll have to figure out a new 
way to handle the PortIndex ... ;( - MLD

Re: force specific Qt5 version install?

[Michael Dickens]

Thank you, Ryan, for that info. I'll have to poke at the Qt5 PortGroup more & 
see what it says about OSX 10.12 and 10.13 since that's where my current issues 
are.

A quick followup from yesterday for this issue on OSX 10.13: I was surprised 
that "port" did indeed "update" -all- of Qt5 from 5.12 to 5.11; it took a few 
internal iterations of "rev-upgrade", but it did succeed eventually.

Here's my wondering today about this Qt5 issue, on my OSX 10.12 boot:
{{{
% uname -a
Darwin mpbr15-10-12 16.7.0 Darwin Kernel Version 16.7.0: Wed Feb 27 00:29:57 
PST 2019; root:xnu-3789.73.43~1/RELEASE_X86_64 x86_64

$ port version
Version: 2019-03-23

[MLD NOTE: I build "port" from "base" GIT master, and use the date of the 
commit for the version in "config/macports_version"; this is the current latest 
GIT master commit.]

$ port outdated
The following installed ports are outdated:
qt5-qtbase 5.12.1_0 < 5.12.2_0   
qt5-qtsvg  5.12.1_0 < 5.12.2_0   

[MLD NOTE: This is correct!]

$ sudo port clean qt5*-qtbase qt5*-qtsvg
Password:
--->  Cleaning qt5-qtbase
--->  Cleaning qt55-qtbase
--->  Cleaning qt56-qtbase
--->  Cleaning qt57-qtbase
--->  Cleaning qt58-qtbase
--->  Cleaning qt59-qtbase
--->  Cleaning qt511-qtbase
--->  Cleaning qt5-qtsvg
--->  Cleaning qt55-qtsvg
--->  Cleaning qt56-qtsvg
--->  Cleaning qt57-qtsvg
--->  Cleaning qt58-qtsvg
--->  Cleaning qt59-qtsvg
--->  Cleaning qt511-qtsvg

[MLD NOTE: This is -not- correct: qt512 doesn't even show up now!]

$ sudo port -p upgrade qt5-qtbase qt5-qtsvg
--->  qt5-qtbase is replaced by qt511-qtbase
--->  Computing dependencies for qt511-qtbase
Error: Can't install qt511-qtbase because conflicting ports are active: 
qt5-qtbase
--->  qt5-qtsvg is replaced by qt511-qtsvg
--->  Computing dependencies for qt511-qtsvg
Error: Can't install qt511-qtsvg because conflicting ports are active: 
qt5-qtbase
Error: Follow https://guide.macports.org/#project.tickets to report a bug.

[MLD NOTE: This is -not- correct. Also: I generally don't use "-p" but here I 
know each port would fail already so I used it just to let "port" try to 
update.]
}}}

Looking at the file "_resources/port1.0/group/qt5-1.0.tcl", I see for this OS 
(os.major == 16):
{{{
} elseif { ${os.major} == 16 } {
#
# macOS Sierra (10.12)
#
# Qt 5.12: Supported
# Qt 5.11: Supported
# Qt 5.10: Supported
# Qt 5.9:  Supported
# Qt 5.8:  Supported
# Qt 5.7:  Not Supported but seems to work
#
return qt5
#
}}}
 so ... not sure why "port" thinks qt511 is the way to go here. I'll admit 
that I didn't poke through the rest of this code, so maybe elsewhere this value 
is ignored / overloaded / overwritten?

Anyway, seems a little fishy here ... - MLD

force specific Qt5 version install?

[Michael Dickens]

On my build computers, I have OSX 10.5 PPC and Intel 10.6 through 10.14; I'm 
still working on 10.4 PPC and 10.5 Intel (I don't think I have the partition 
space for 10.4 Intel, even if I wanted to install it, which I'm not sure I do). 
I am regularly struggling to get Qt5 to update and sometimes even install, 
especially on 10.10 through 10.13.

For example, right now on 10.13 I have Qt5 5.12.1 installed. "port" says that 
there is an update for qt5-qtbase and qt5-qtsvg ... to 5.11.3! Doing "sudo port 
upgrade outdated" fails because "port" can't figure out how to do the upgrade 
of the various Qt5 ports. [For the fun of it, I force uninstalled those ports 
(version 5.12.1) and then did "sudo port rev" and let "port" try to install the 
version of Qt5 it thinks is the correct version for this OS. I'm guessing once 
those ports at version 5.11.3 are installed, "port" will complain about ABI 
issues with the other Qt5 ports (which are at 5.12.1) ... we'll see!]

I see this Qt5 upgrade issue regularly, and usually "port" eventually figures 
out the correct version of Qt5 to install -- sometimes it takes some coercion, 
but after much ado I have a Qt5 working; I have no idea if it's truly the 
latest / best build for the OS, but "port" thinks so & thus I'm willing to go 
along with it.

Is there a way to force "port" to try to install a given Qt5 version? For 
example I know for a fact that 5.12.1 is buildable (and usable) on OSX 10.13 
(since it was installed before this "update"), regardless of what "port" thinks.

Thanks for whatever thoughts y'all MacPorts developers have here! - MLD

C11 compiler selection?

[Michael Dickens]

Do we have a portgroup or whatever to select a compiler for c11 compliance? In 
my testing using the c++11 1.1 PG isn't sufficient ... which might mean that 
the c++11 compiler compliance selection isn't correct (but I doubt it); or that 
c11 compiler compliance selection is different that that for c++11 (which is my 
guess). In a quick search I can find nothing obvious to do this in MP. Thanks 
for your thoughts / insights! - MLD  (ps> I need this for the latest 
GLFW-devel, which uses  ...)

Re: Where to draw the line between Qt 4 and 5

[Michael Dickens]

CMake has the same dilemma.

I'm using Qt4 on macOS 10.14 latest & see no issues on a retina display 
excepting that the "retina" concept isn't supported. IIRC we've added tweaks to 
allow the user to select the default rendering engine, and that took care of 
all of the issues I've heard of or seen (or, maybe it was a PR that never got 
finished? I no longer recall ...). If there is a scaling issue (beyond the lack 
of support for the "retina" concept) then I'd love to hear what it is. I'm 
amazed that Qt4 still works as well as it does on 10.14, TBH!

Related about Qt5: I have issues getting it installed even on OSX 10.11 when 
using MacPorts! I believe this is because of MP programming and not Qt5 stuff, 
but whatever IDK. I've tried "update" and direct "install" with no success; 
I've yet to try "deactivate" then "install", but that's next up the current 
updates finish.

Also related: I don't actively use Qt5 yet like I used to use Qt4, so maybe 
someone else knows the answer here: does each successive version of Qt5 have 
both API and ABI changes that make them backward-incompatible with prior 
versions? I'm guessing the answer is "yes". If so, then is the "feature set" 
for a given port relevant for selecting which version of Qt5 will work with it? 
I -hope- the answer here is "maybe but not generally" otherwise how could we 
make sure the proper version of Qt5 is installed for all the various ports 
requiring their different feature sets?

I really don't know what a good cutoff is between Qt4 and Qt5 for the default 
if both can work. If I had to guess, I'd say Y == 10.9 and X == 10.11 right now 
... but maybe expand those to 10.8 and 10.12 maximally. Just a guess based on 
my recent Qt5 updating / installing experiences ...

Hope this is useful! - MLD

On Thu, Feb 28, 2019, at 9:59 AM, Mojca Miklavec wrote:
> Hi,
> 
> I would like to update Mercurial & TortoiseHG, but I don't know on
> which OS Qt 5 may be declared as default one. Note that both Qt 4 and
> 5 work fine (see below), so it doesn't really matter which one is used
> and I wouldn't want to break old OSes just because of a stupid
> hardcoded requirement of Qt 5.
> 
> I don't want to make Qt 4 default on newer OSes either because it
> doesn't work correctly on Retina display (many buggy issues with
> scaling), but that's the last thing to worry about on 10.5.
> 
> I thought that maybe we should make Qt 5 default on darwin >= X, Qt 4
> default on darwin < Y and potentially offer variants on Y <= darwin <
> X and defaulting to Qt 4 (where we may set X = Y, making this subset
> empty).
> 
> So: where should I draw the line? What should X/Y be?
> 
> The relevant PR is here:
> https://github.com/macports/macports-ports/pull/3664
> 
> Thank you,
> Mojca
>

Re: compilers that support thread-local storage?

[Michael Dickens]

Or ... maybe not! Looks like the cxx11 1.1 PG conflicts with the compilers PG & 
I end up with just g95 for the Fortran compiler selection ... oops!

I'll just replicate the compiler blocklist per your description & go with that. 
Will work on older OSX & won't harm on newer OSX. - MLD

On Wed, Feb 13, 2019, at 1:41 PM, Michael Dickens wrote:
> OK wow that's quite the analysis! I'm going to go with just 
> incorporating the c++11 1.1 PG ... it'll work for now, and once "we" get 
> around to dealing with the changes to base from PR #88, it'll be a 
> "universal" change to all Portfiles that use c++11 PGs ... so we'd be 
> good to go! Thanks! - MLD
> 
> On Wed, Feb 13, 2019, at 1:23 PM, Ken Cunningham wrote:
> > __thread came first, then thread_local a bit later. 
> > 
> > the difference is that thread_local allows more complicated initializers 
> > and destructors ("non-trivial"). It is c++11, as you said.
> > 
> > 
> > quite old gcc versions support __thread  I think the earliest one was 
> > gcc 4.1 
> > <https://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Thread_002dLocal.html>
> > 
> > gcc 4.8+  supports thread_local 
> > <https://www.gnu.org/software/gcc/gcc-4.8/changes.html>
> > 
> > 
> > For Open Source clang, we have this reference 
> > <https://clang.llvm.org/cxx_status.html> that shows clang-3.3+ supported 
> > it with a proper runtime. That runtime exists on 10.7+. As you know, I 
> > have recently enabled "emulated thread_local" on clang-5.0+ (to match up 
> > with the c++11 PG) for both stdlib=libc++ and stdlib=macports-libstdc++ 
> > (our c++11 runtimes). I wasn't planning on porting that back any 
> > further.
> > 
> > 
> > For Xcode clang, you already have that -- 900+. Apple introduced a 
> > better-performance thread_local system that (as I understand it) 
> > involved integration into dyld .
> > 
> > 
> > 
> > So gcc-4.8+ and clang-5.0+ is reliable on all systems using a c++11 
> > runtime, although there are some systems that can use thread_local with 
> > clang-3.4 to clang-4.0 it appears (untested by me).
> > 
> > My idea was to make the cxx11 PG more or less == thread_local capability. 
> > 
> > This has _all_ been changed in base recently by Marcus' base PR #88, so 
> > it's a moving target.
> > 
> > Ken
> > 

Re: compilers that support thread-local storage?

[Michael Dickens]

OK wow that's quite the analysis! I'm going to go with just incorporating the 
c++11 1.1 PG ... it'll work for now, and once "we" get around to dealing with 
the changes to base from PR #88, it'll be a "universal" change to all Portfiles 
that use c++11 PGs ... so we'd be good to go! Thanks! - MLD

On Wed, Feb 13, 2019, at 1:23 PM, Ken Cunningham wrote:
> __thread came first, then thread_local a bit later. 
> 
> the difference is that thread_local allows more complicated initializers 
> and destructors ("non-trivial"). It is c++11, as you said.
> 
> 
> quite old gcc versions support __thread  I think the earliest one was 
> gcc 4.1 
> 
> 
> gcc 4.8+  supports thread_local 
> 
> 
> 
> For Open Source clang, we have this reference 
>  that shows clang-3.3+ supported 
> it with a proper runtime. That runtime exists on 10.7+. As you know, I 
> have recently enabled "emulated thread_local" on clang-5.0+ (to match up 
> with the c++11 PG) for both stdlib=libc++ and stdlib=macports-libstdc++ 
> (our c++11 runtimes). I wasn't planning on porting that back any 
> further.
> 
> 
> For Xcode clang, you already have that -- 900+. Apple introduced a 
> better-performance thread_local system that (as I understand it) 
> involved integration into dyld .
> 
> 
> 
> So gcc-4.8+ and clang-5.0+ is reliable on all systems using a c++11 
> runtime, although there are some systems that can use thread_local with 
> clang-3.4 to clang-4.0 it appears (untested by me).
> 
> My idea was to make the cxx11 PG more or less == thread_local capability. 
> 
> This has _all_ been changed in base recently by Marcus' base PR #88, so 
> it's a moving target.
> 
> Ken
> 

compilers that support thread-local storage?

[Michael Dickens]

I'm wondering what the correct blacklist is to get compilers that support 
thread local storage.

I've found some Portfiles that state just:
{{{
compiler.blacklist-append {clang < 800.0.38}
}}}
which isn't enough since I know that the old Apple GCC and LLVM versions from 
4.2 and older won't work ... so adding also:
{{{
compiler.blacklist-append cc {*gcc-3*} {*gcc-4.[0-2]}
}}}

What I don't know is which version of GCC did thread local storage start? Maybe 
with c++11, which would be IIRC 4.6, so also:
{{{
compiler.blacklist-append {*gcc-4.[3-5]}
}}}

Or: can I just use the C++11 PortGroup?

What's the best / correct way to do this?

Thx! - MLD

Re: OSX 10.6 clang / llvm circular dependency

[Michael Dickens]

awesome! looking forward to having this issue behind me! I'll check out your 
changes this afternoon ... - MLD

On Mon, Feb 11, 2019, at 11:37 AM, Ken Cunningham wrote:
> Someone, maybe me, forgot to blacklist clang 7.0 when building clang 7.0. 
> 
> It's a 10 second fix in the portfile; I'll take care of it in a few minutes.
> 
> Thanks for noticing.
> 
> Ken

Re: OSX 10.6 clang / llvm circular dependency

[Michael Dickens]

clang-7.0 is not installed yet on these systems ...

On Mon, Feb 11, 2019, at 11:28 AM, Ken Cunningham wrote:
> Please try deactivating clang-7.0 and then see what it says.
> 
> the clang & llvm ports do conditional blacklisting depending on what is 
> installed.
> 
> The ports build on all systems, so it is working out, but perhaps I need 
> to tweak something --- as you say, should never depend on itself.
> 
> Ken

Re: OSX 10.6 clang / llvm circular dependency

[Michael Dickens]

I just moved one of my build computers from OSX 10.10 to OSX 10.9, and I see 
the same issue with Clang / LLVM 7.0. It seems to impact just Clang / LLVM 6.0 
and 7.0 thus far, but it still exists; this is a completely separate install 
from my 10.6 -- different computer and partition. I didn't seem to encounter it 
when updating OSX 10.10 or later, but I also wasn't looking specifically so it 
might have been there & I just missed it. When I move to 10.8 aand earlier 
(and, back to 10.10 and later) I'll look specifically. Guessing the difference 
as noted is between the latest release and the latest GIT master. I haven't 
done a commit review to track down the culprit, but hopefully I'll get there in 
the coming days. - MLD

Re: OSX 10.6 clang / llvm circular dependency

[Michael Dickens]

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

Re: OSX 10.6 clang / llvm circular dependency

[Michael Dickens]

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

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

Re: OSX 10.6 clang / llvm circular dependency

[Michael Dickens]

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

Re: OSX 10.6 clang / llvm circular dependency

[Michael Dickens]

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

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

Re: OSX 10.6 clang / llvm circular dependency

[Michael Dickens]

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

Re: OSX 10.6 clang / llvm circular dependency

[Michael Dickens]

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

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

OSX 10.6 clang / llvm circular dependency

[Michael Dickens]

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

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

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

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

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

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

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

Re: c++ -std= strangeness

[Michael Dickens]

After some reading about the C++ standards, I believe that older standards do 
not prohibit having future-looking functions or classes in place. That said, I 
also find nothing regarding any such "future-looking functions or classes" in 
Clang [note: some people call these "extensions", like as provided by the GNU 
project -- and, thus requested via "-std=gnu++XY" instead of the usual 
"-std=c++XY".

I'm investigating this issue more today, trying a list similar to what Jeff 
Dalton did for this GCC bug for C < 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017 > except for C++.

The good news is that we now have the legacy support project where such 
overlooked functions can be declared (if part of the ABI but not API), and/or 
defined (if not part of either the ABI or API when they should be). I believe 
that either can be accomplished pretty straight forwardly. We'll see & more as 
I find it! - MLD

On Tue, Feb 5, 2019, at 12:07 AM, Joshua Root wrote:
> On 2019-2-5 13:59 , Michael Dickens wrote:
> > The interesting strangeness is that the clang++ compilers (both Apple and 
> > MP) do not generate errors when using -std=c++98 or -std=c++03 ... which is 
> > wrong! The #warning printout indicates that the correct __cplusplus is 
> > selected, but the build should not succeed! All g++ compilers correctly 
> > error out with these -std settings.
> > 
> > This lack of compliance at least by default is troubling! Maybe I'm missing 
> > something here? Are there some other flags I should be setting to keep 
> > clang from figuring out the c++ standard and using it instead of what I 
> > specify -- if this is the issue?
> 
> Are you certain that the C++98/03 standards prohibit the standard
> library from providing this function? It may well be that an
> implementation is compliant as long as everything specified in the
> standard is present and behaves correctly; providing additional
> functionality may be irrelevant.
> 
> - Josh

c++ -std= strangeness

[Michael Dickens]

Yet another interesting oddity came up in my debugging today trying to fix 
CMake to build correctly on OSX 10.5 PPC(32). The issue is in the use of 
std::lround, which is defined for c++11 and newer only, and, was possibly not 
included as part of c++11 in GCC[4-6] ... it is apparently included in GCC7 and 
newer.

This got me going down a rabbit hole with regard to __cplusplus (set via the 
-std flag) and building code that calls std::lround, so I created a simple test 
file as follows:
{{{
#if __cplusplus == 201707L
#warning "Using STD c++2a (will be c++20)"
#elif __cplusplus == 201703L
#warning "Using STD c++17 or c++1z (will be c++17)"
#elif __cplusplus == 201402L
#warning "Using STD c++14"
#elif __cplusplus == 201103L
#warning "Using STD c++11"
#elif __cplusplus == 199711L
#warning "Using STD c++98 or c++03"
#endif

#include 
#include 

int
main
(void)
{
  std::cout << "lround(+2.3) = " << std::lround(2.3) << std::endl;
  return 0;
}
}}}

Then, I compile this code using various -std=c++XY or gnu++XY ... doesn't 
really matter for this example. I also use the following compilers:

* clang++ :Apple LLVM version 10.0.0 (clang-1000.11.45.5)
* clang++-mp-7.0 : clang version 7.0.1 (tags/RELEASE_701/final)
* g++-mp-8 : gcc version 8.2.0 (MacPorts gcc8 8.2.0_3)
* g++-mp-9 : gcc version 9.0.1 20190127 (experimental) (MacPorts gcc9 
9-20190127_0)

The interesting strangeness is that the clang++ compilers (both Apple and MP) 
do not generate errors when using -std=c++98 or -std=c++03 ... which is wrong! 
The #warning printout indicates that the correct __cplusplus is selected, but 
the build should not succeed! All g++ compilers correctly error out with these 
-std settings.

This lack of compliance at least by default is troubling! Maybe I'm missing 
something here? Are there some other flags I should be setting to keep clang 
from figuring out the c++ standard and using it instead of what I specify -- if 
this is the issue?

Thanks for any feedback! - MLD

Re: rpath argument change in GCC / LD

[Michael Dickens]

Ken and I are discussing off-list too :)

gfortran is interpreting the '-Wl,-rpath' flag provided to it. In our testing 
both "-Wl,-rpath,PATH" and "-Wl,-rpath -Wl,PATH" work, but "-Wl,-rpath=PATH" 
does not work. Doesn't seem to matter if PATH or "PATH" (quoted or not).

It could be that gfortran8 behaves differently than gfortran[4-7] or gfortran9 
... I don't know yet, but I'm testing on older OSX to try to figure out the 
pattern.

I'm not sure why my current NumPy patch to tweak the rpath here isn't working, 
since it -should- produce '-Wl,-rpath -Wl,"PATH"' ... I'll keep bashing on it 
... - MLD

On Mon, Feb 4, 2019, at 11:39 AM, Chris Jones wrote:
> Hi,
> 
> Hmmm, quite right.
> 
> Then perhaps what you are now seeing are the changes
> 
> 
> 
> That is from July last year though - There have been no significant 
> changes since then. I don't know why Michael would only seem this now ?
> 
> Anyway, note the above does mean there is a difference in behaviour 
> depending on Xcode version.
> 
> Chris
> 
> On 04/02/2019 4:02 pm, Ken Cunningham wrote:
> >> If the port is using the as version from cctools
> > 
> > Hey, Chris — all that applies to the assembler, but Michael is trying to 
> > beat the linker into submission.
> > 
> > K
> > 

Re: rpath argument change in GCC / LD

[Michael Dickens]

So from your list below as I've labeled them, only (3) works in my testing with 
GCC8 as the pass-through compiler between the SciPy script creating this code & 
the linker. I have not tested any other GCC version, but I'm guessing it's the 
linker that's called that determines whether the -rpath flag usage is valid. As 
I said: This is a fairly recent change in the linker, which I'm guessing has 
something to do with which linker is being used: MP's or Xcode's. All of my 
testing over the weekend was on 10.14, which passes the link command through to 
Xcode's linker. I will try testing on my older OSX boxes to see what happens 
there, since I'm guessing they use MP's linker (as Xcode's is so old). If (3) 
works on all of the linkers, then I'll go with it (patching to include the 
""s). - MLD

On Mon, Feb 4, 2019, at 12:22 AM, Ken Cunningham wrote:
> My understanding is that this should not work:
> 
(1) > -Wl,-rpath=“DIR”
> 
> But these two are functionally the same, assuming they are not reordered.
> 
(2) > -Wl,-rpath -Wl,”DIR”
> 
> or 
> 
(3) > -Wl,-rpath,”DIR”
> 
> Both are sent to the linker as two options sequentially:
> 
> -rpath “DIR”
> 
> Ken

rpath argument change in GCC / LD?

[Michael Dickens]

I'm trying to update NumPy to 1.61.1, with some success ... but have come up 
with something odd with respect to the distutils/fcompiler/gnu.py provided 
within NumPy: the "rpath" setting that I fixed a little over 2 years ago has 
reared its ugly head!

The original code at the time was (NumPy 1.11.2):
{{{
-Wl,-rpath="DIR"
}}}
where DIR is the rpath directory (unquoted). These flags are being appended to 
the Fortran build command for linking libraries (technically .so objects).

With some trial and error testing, my change back ~2 years ago fixed this to 
instead be:
{{{
-Wl,-rpath -Wl"DIR"
}}}

The original code is now as of NumPy 1.16.1:
{{{
-Wl,-rpath,DIR
}}}
... note the "," separator and unquoted DIR.

Up until some recent time, my fix worked. Then ... something changed, and the 
now-original code seems to work in my testing: installing NumPy then trying to 
build SciPy & changing this specific line of code between SciPy builds verifies 
the use of "-rpath,DIR" ... or, probably better would be '-rpath,"DIR"' in case 
the DIR has spaces in it.

Since these flags are being passed through to the linker (ld), I have to 
believe that what changed is the acceptable linker arguments for doing rpath.

I know there's been quite a bit of kerfuffle recently about ld64 and using 
xcode's versus MP's actual linker. Maybe this makes a difference? Does the 
rpath argument to the linker depend on which linker is being used? Does the 
linker used depend on the version of OSX? Can we select a single "-rpath" 
argument setting here to use so that it works with all linkers?

I'm hoping others can shed some light here so that I can get NumPy updated & 
properly working for all of the potential linkers we might now use. Thx! - MLD

Re: Boost: why "--layout==tagged"?

[Michael Dickens]

OK yes we -offer- multiple versions, but only one version can be installed at a 
time right now. And, when using "--layout==tagged" I'd bet that the resulting 
ABI name changes for each installed variant, which means that all ports that 
depend on Boost would have to be rebuilt when switching between variants.

I firmly believe that the vast vast majority of folks pick their Boost variant 
and stick with it through the lifetime of that Boost version if not the whole 
MacPorts install. The number of folks who actively switch between Boost 
variants is IMHO very very small.

One can always do "port installed boost and active" to determine which variants 
were selected for the specific Boost install. Hence, if I'm otherwise correct 
about folks' usage of Boost, then the actual ABI name makes no real difference: 
for linking purposes, for reading purposes, for any other purposes.

This is my argument for moving from "tagged" back to "system": it might 
inconvenience a very small number of folks, but at the same time it will make 
Boost easier to maintain for those of us trying to do so. - MLD

ps> Subports could be made to work instead of variants -- and I'd love to see 
those for Boost::Python versions for example to be able to install whichever 
versions we want at the same time since the API is the same but the ABI names 
will be different starting with Boost 1.68.0 (or maybe even 1.67.0) -- but I'd 
still like the "default" Boost install to be "system" naming. I don't have time 
to even do the Boost::Python subports right now & likely won't for months, let 
along all of Boost!

On Fri, Feb 1, 2019, at 1:11 PM, Ryan Schmidt wrote:
> We *do* offer multiple versions, four in fact: single-threaded static, 
> single-threaded dynamic, multithreaded static, and multithreaded 
> dynamic.
> 
> We have variants with (ill-advised) names no_static and no_single to 
> disable some of those. We enable both of those variants by default to 
> speed up building; the decision to do that predates the existence of 
> precompiled port binaries in MacPorts 2 which make the speed issue 
> irrelevant for those users who get binaries.
> 
> Really, we should have moved the multithreaded and single-threaded 
> versions to separate subports.
> 
> If we want to delete the ability of MacPorts to offer the single-
> threaded version, we can certainly do that. I don't know what the 
> consequence of doing that would be. I don't know if anybody is currently 
> relying on the single-threaded versions. If they are, silently 
> "upgrading" them to the multithreaded versions as you propose will 
> certainly break their use case.
> 
> If we do make the change, of course we have to revbump everything that 
> links with boost. There are also a zillion places where the "-mt" suffix 
> had to be passed to build systems, either via arguments in the Portfile 
> or with patchfiles; all those instances would have to be found and 
> changed.

Re: A quick question on PR etiquette

[Michael Dickens]

My vote: All in 1! (and 1 for all!)

On Sun, Jan 20, 2019, at 1:45 PM, Mark Anderson wrote:
> So, I want to change my email on all of my ports. Should I do them all
> in one big PR which is what my gut says, or should I do a separate one
> for each? It'd be the only change I'd make in this pass.> 
> Thanks,
> Mark

Boost: why "--layout==tagged"?

[Michael Dickens]

I've been trying to get Boost 1.69.0 working, without much luck yet because the 
default installed library names as installed by MacPorts are changed from 
"libboost_COMP-mt.dylib" to "libboost_COMP-mt-ARCH.dylib", where "COMP" is the 
component name (e.g., "system", "thread") and "ARCH" is the abbreviated 
architecture (e.g., "x64" for Intel x86 64-bit, "p32" for PPC 32-bit).

None of the build systems that I've checked (cmake and autotools) recognizes 
this style of library name. I think I can coerce CMake into working, but it's a 
bit of a hack & may not work work universally. I'd guess I can do the same for 
other build systems, but each is unique & hence I'd rather get rid of the ARCH 
part of the library names. Which got me wondering about why the whole "mt" part 
too.

After some sleuthing, I find that one reason for the library name change is 
that in the Boost Portfile we're using build.args of "--layout=tagged" rather 
than the default of "--layout=system". When using the latter, I get just the 
basic library names: "libboost_COMP.dylib", which to me actually makes the most 
sense: the goal of "tagged" is to allow simultaneous / parallel installation of 
multiple Boost libraries: single ("") & multi-threaded "-mt"; different ARCH 
("-x64", "-p32" etc); different compilers and compiler versions ("clang10", 
"gcc8", etc)... you get the idea.

For all practical purposes, we in MacPorts-land just install Boost ... one 
version, and that's it. We don't need all of the tagged naming for multiple 
versions installed -- at least not in my experience or opinion.

The commit that moves from "system" to "tagged" goes -way- back: < 
https://github.com/macports/macports-ports/commit/2dbce9b6303f26dc055c53d3302f8c158c025294
 > ... by Anthony Ramine committed on Jun 19, 2009.

So  wondering what folks think about moving back to "system" here and just 
the basic library names. I'm all for it; if you're not, I'd wonder why not? - 
MLD

Re: leave revision 0 line in Portfile

[Michael Dickens]

I'm in agreement here about keeping "revision 0" lines & will start 
implementing this in my ports as they get updates. - MLD

On Sun, Dec 23, 2018, at 5:54 AM, Mojca Miklavec wrote:
> Dear Ken,
> 
> On Sat, 22 Dec 2018 at 16:49, Ken Cunningham wrote:
> >
> > I would like to propose we stop asking people to remove the "revision 0" 
> > line in Portfiles.
> 
> I totally agree.
> 
> I mean:
> - if users submit a PR with "revision 0", we should not ask them to
> remove that line
> - if users submit a PR with revision removed, we should not ask them
> to add it back either (at least not until we add that line to all
> other ports for some well-grounded reasons)
> - if users forget to change "revision 99" after version increase, we
> should still ask them to either remove it or change it to 0
> 
> > So how about we embrace the "0" and move on to stuff that matters more!!!
> 
> +1
> 
> Mojca

Re: Q about post-extract recent commit breakage

[Michael Dickens]

Ah yes; very good! Thanks for that fix; it should be removed with the next MP 
release, yes? - MLD

On Wed, Dec 5, 2018, at 5:05 AM, Ryan Schmidt wrote:
> On Dec 4, 2018, at 12:03, Michael Dickens wrote:
> > Or, even more simply, just remove the post-extract all together. I don't 
> > recall why it's the in the first place, but removing it seems to do the 
> > trick. Thanks! 
> 
> That works with the not-yet-released MacPorts master version, but does 
> not work with the released MacPorts 2.5.4; for that version, you still 
> need to set worksrcdir manually when it is not the default value. Fixed 
> in 860f9c647f60a33043e8a13dfe688c575faa88cd.

Re: Q about post-extract recent commit breakage

[Michael Dickens]

Or, even more simply, just remove the post-extract all together. I don't recall 
why it's the in the first place, but removing it seems to do the trick. Thanks! 
- MLD

On Tue, Dec 4, 2018, at 2:07 AM, Ryan Schmidt wrote:
> On Dec 4, 2018, at 01:04, Ryan Schmidt wrote:
> 
> > On Dec 3, 2018, at 19:35, Michael Dickens wrote:
> > 
> >> Here's the error (just do "sudo port extract cmake-devel"; it results in 
> >> this error on every OS I tested, from 10.5 to 10.14):
> >> {{{
> >> Error: Failed to extract cmake-devel: error renaming 
> >> "/opt/local/var/macports/build/_opt_sources_MacPorts_ports_github_macports_devel_cmake/cmake-devel/work/cmake-772edffbf0c08fc0a6fcf74fb98545b7afcfee13-772edffbf0c08fc0a6fcf74fb98545b7afcfee13"
> >>  to 
> >> "/opt/local/var/macports/build/_opt_sources_MacPorts_ports_github_macports_devel_cmake/cmake-devel/work/cmake-772edffbf0c08fc0a6fcf74fb98545b7afcfee13/cmake-772edffbf0c08fc0a6fcf74fb98545b7afcfee13-772edffbf0c08fc0a6fcf74fb98545b7afcfee13":
> >>  trying to rename a volume or move a directory into itself
> >> Error: See 
> >> /opt/local/var/macports/logs/_opt_sources_MacPorts_ports_github_macports_devel_cmake/cmake-devel/main.log
> >>  for details.
> >> }}}
> > 
> > Ok, that's because cmake-devel does this:
> > 
> >post-extract {
> >move ${workpath}/${name}-${commit}-${commit} 
> > ${workpath}/${name}-${commit}
> >}
> > 
> > Now that base has been changed, MacPorts has already made a ${worksrcdir} 
> > (in this case ${name}-${commit}) symlink for you. So for compatibility with 
> > both the released version of MacPorts and master, you should ensure it 
> > doesn't already exist before moving it:
> > 
> >post-extract {
> >if {![file exists ${worksrcpath}]} {
> >move ${workpath}/${name}-${commit}-${commit} ${worksrcpath}
> >}
> >}
> > 
> > which is basically what's done in the remaining commit for libao in this PR:
> > 
> > https://github.com/macports/macports-ports/pull/1760
> > 
> > After compatibility with the current version of MacPorts is no longer 
> > needed, the entire post-extract block can be removed.
> 
> Or, more simply and more usually, you should be able to just:
> 
> worksrcdir${name}-${commit}-${commit}
> 
> (and again, if desired, remove it once a future version of MacPorts is 
> released).
> 

Re: Q about post-extract recent commit breakage

[Michael Dickens]

Here's the error (just do "sudo port extract cmake-devel"; it results in this 
error on every OS I tested, from 10.5 to 10.14):
{{{
Error: Failed to extract cmake-devel: error renaming 
"/opt/local/var/macports/build/_opt_sources_MacPorts_ports_github_macports_devel_cmake/cmake-devel/work/cmake-772edffbf0c08fc0a6fcf74fb98545b7afcfee13-772edffbf0c08fc0a6fcf74fb98545b7afcfee13"
 to 
"/opt/local/var/macports/build/_opt_sources_MacPorts_ports_github_macports_devel_cmake/cmake-devel/work/cmake-772edffbf0c08fc0a6fcf74fb98545b7afcfee13/cmake-772edffbf0c08fc0a6fcf74fb98545b7afcfee13-772edffbf0c08fc0a6fcf74fb98545b7afcfee13":
 trying to rename a volume or move a directory into itself
Error: See 
/opt/local/var/macports/logs/_opt_sources_MacPorts_ports_github_macports_devel_cmake/cmake-devel/main.log
 for details.
}}}

On Mon, Dec 3, 2018, at 8:32 PM, Ryan Schmidt wrote:
> 
> 
> On Dec 3, 2018, at 09:55, Michael Dickens wrote:
> 
> > Re: < 
> > https://github.com/macports/macports-base/commit/7921b2e05e9a4c9cda6efedee496affb305dcc07
> >  >:
> > {{{
> > Date:   December 29, 2017 at 10:54:09 AM EST
> > Author: Andrew L. Moore slewsys@...
> > Committed by Mojca Miklavec mojca@...
> > 
> > portextract: Create symlink if no $worksrcpath
> > 
> > If expected extract path doesn't exist, create a symlink
> > from expected directory to the actual one.
> > If $worksrcdir is explicitly set, nothing is done.
> > }}}
> > 
> > This commit breaks the extract for "cmake-devel". Is the issue with the 
> > Portfile, or with the commit? I'll look into this issue when I have a 
> > chance, but maybe someone else (Mojca?) will get there first! - MLD
> 
> That PR was submitted a year ago. It was high time to merge it.
> 
> https://github.com/macports/macports-base/pull/55
> 
> It was hoped that this would make many ports easier to write, without 
> needing to set worksrcdir. Much testing was done to determine what 
> negative impact this change might have, and some ports were identified 
> that needed changes to be compatible with this. Most of those ports were 
> already fixed to be compatible with both current MacPorts and the above 
> PR. Looks like as of today only one port remains to be modified:
> 
> https://github.com/macports/macports-ports/pull/1760
> 
> It is certainly possible that some ports were missed. If you need help 
> figuring out what to do with cmake-devel, let us know what the error is.

Q about post-extract recent commit breakage

[Michael Dickens]

Re: < 
https://github.com/macports/macports-base/commit/7921b2e05e9a4c9cda6efedee496affb305dcc07
 >:
{{{
Date:   December 29, 2017 at 10:54:09 AM EST
Author: Andrew L. Moore slew...@gmail.com
Committed by Mojca Miklavec mo...@macports.org

portextract: Create symlink if no $worksrcpath

If expected extract path doesn't exist, create a symlink
from expected directory to the actual one.
If $worksrcdir is explicitly set, nothing is done.
}}}

This commit breaks the extract for "cmake-devel". Is the issue with the 
Portfile, or with the commit? I'll look into this issue when I have a chance, 
but maybe someone else (Mojca?) will get there first! - MLD

Re: Issues with clock_gettime(CLOCK_REALTIME, ) pre macOS 10.13

[Michael Dickens]

OSX sometimes doesn't provide useful features, or has issues. I love the idea 
of the `snowleopardfixes` port to provide and fix for Snow Leopard. I'd support 
expanding the concept to other missing features such as this `clock_gettime` 
for ports installing on OSX that doesn't provide this functionality (ditto for 
`posix_memalign`). Doing this would greatly simplify some port patches as well 
as provide better older-OS compatibility; also keeps these fixes in 1 place for 
easier maintenance and referral. Seems like a reasonable solution to me! - MLD

On Tue, Oct 23, 2018, at 10:15 AM, Ken Cunningham wrote:
> We have worked around this in a number of ports so far, and turned off 
> some functionality in others.
> 
> I use the_silver_searcher to find stuff like this, for example in the 
> macports-ports repo:
> 
> ag -i clock_gettime .
> 
> 
> Best,
> 
> Ken

Re: Merging pull requests before 72 hours

[Michael Dickens]

I'll second Chris' note of thanks for MP folks keeping the PR queue short. 
Since MP folks (especially Perry) have started stepping up to this task, I too 
have been trying harder to do my part.

Now my US$0.02 worth and all IMHO about PR commit timeouts & why. - MLD

-Any- non-urgent fix should go under a 72-hour timeout; urgent fixes should be 
given 24 hours. "Urgent" means that the port is clearly broken in any sense: 
fetch, patch, configure, build, destroot, install, activate, runtime -- on the 
most recent supported OSs (currently: 10.12-10.14). If a port works on recent 
OSs but is broken on an older OS, e.g., 10.6 or 10.8, then it goes under a 
72-hour timeout.

Rationale: I like reviewing changes, even trivial ones, to my ports. I'm often 
unavailable on weekends (USA Sa/Su), so an issue filed on Saturday I generally 
won't get to until Monday. 72 hours gives any maintainer(s) a reasonable chance 
to review, request changes, discuss, decide to merge, and so forth. 24 hours 
just isn't enough most of the time, given our various work and family lives.

I, too, would like to see a clear set of guidelines, not just the use of 
"major" or "minor" since those are very subjective.

Re: Commit History vs User Convenience

[Michael Dickens]

In my opinion: A single rev-bump is required when changes to the overall 
Portfile require it -- whether a single commit or multiple commits in a PR. The 
overall goal of a rev-bump is to force the port to be updated; it is a 
developer necessity & it's value is really not for the user's convenience.

I'd say so long as you note specifically in the commit message that a rev-bump 
-should- be done here but you're holding off for a future commit within the 
same PR, then that meets all of the basic requirements: it provides history & 
rationale, and still does the required rev-bump.

To be fair: One could, of course, clone the MP GIT repo & check out the interim 
commit (without the rev-bump) ... but, I don't see why anyone would want to do 
this & if they are sophisticated enough to do this then they can figure out the 
rev-bump issue too.

My US$0.02 worth ... - MLD

On Mon, Oct 8, 2018, at 10:13 AM, Marcus Calhoun-Lopez wrote:
> 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

Re: qreduce

[Michael Dickens]

You can do whatever you want in a subport, and it is executed just for that 
subport. You can have different subports in the same file with entirely 
different dependencies, descriptions, livecheck, build, etc; I don't recommend 
doing this, but if there's justification then one can do it. - MLD

On Sat, Oct 6, 2018, at 4:09 PM, Mark Brethen wrote:
> Reduce, libreduce and PySide are required to build and run qreduce. Can 
> you override dependancies in a subport?
> 
> 
> Mark Brethen
> mark.bret...@gmail.com

Re: qreduce

[Michael Dickens]

Hi Mark - Do they have the same basic description, dependencies, homepage, and 
build requirements? If so, then a subport could work. If any of these are 
significantly different, then I'd recommend not doing a subport. My US$0.02 
worth ... - MLD

On Sat, Oct 6, 2018, at 3:41 PM, Mark Brethen wrote:
> I’m working on a port qreduce-devel. This is a Qt-based worksheet GUI 
> (written in python) for Reduce UNDER DEVELOPMENT. Would this be suited 
> as a separate port or is it considered a sub-port of reduce? BTW the 
> source is packaged with the reduce source.
> 
> Mark Brethen
> mark.bret...@gmail.com

Re: Adding a Code of Conduct to MacPorts

[Michael Dickens]

Related, sort of: < 
https://www.newyorker.com/science/elements/after-years-of-abusive-e-mails-the-creator-of-linux-steps-aside
 >

In my experience, we in MacPorts-land don't have the obvious Linux issue. I 
hope others don't experience the MacPorts project (developers, users, 
commenters) as abusive in any medium (email lists, tickets / issues, PR's, in 
person, whatever). - MLD

Re: Adding a Code of Conduct to MacPorts

[Michael Dickens]

I definitely agree that when a document enumerates examples -- even with the 
"including but not limited to" -- it sets the stage for your scenario. Thus, 
moving away from examples is probably wise. I, too, like the Ruby CoC: it's 
short and concise, stating the basic principles rather than specifics. It might 
be overly vague and open to interpretation, but that's OK. Anyway, thanks for 
that info, George. It's definitely worth considering how detailed or vague we 
in MacPorts-land would like any CoC we might adopt. - MLD

On Wed, Sep 19, 2018, at 12:32 AM, George Plymale II wrote:
> I'm fairly new in the MacPorts community, but I'd like to offer an
> opinion on this topic. Personally, I feel that CoC's like the
> Contributor Covenant, Postgres CoC, FreeBSD CoC, etc. are very... umm,
> let's just say strict. I think they read more like license terns than a
> set of guidelines on how to be friendly in a community. The real problem
> with them seems to be with the fact that they're so specific. This means
> in practice that Bob will point to it and say, "Alice did this to me"
> and then Alice will come back and say, "well I wasn't breaking any rules
> because it wasn't included in your CoC."
> 
> I know that kind of situation sounds silly, but this is the kind of
> thing that happens with these sorts of CoC's. I personally prefer a
> human-driven approach, where people take things on a case-by-case
> basis. I.e., people can decide whether someone is being unreasonable or
> not and it is a much healthier way of doing things in my
> experience. I've seen lots of drama in the past due to people trying to
> force these unnatural CoC's upon projects and it results in more harm
> than good.
> 
> I personally vouch for the Ruby Code of Conduct. Here is a link:
> https://www.ruby-lang.org/en/conduct/
> 
> I think it encapsulates the basis of a friendly community while being
> succinct. I really doubt that any problems will arise like this in the
> future, but I think that having a healthy CoC will be good for everyone.
> 
> Just my 2¢

Re: Adding a Code of Conduct to MacPorts

[Michael Dickens]

I'll second that having a CoC isn't a bad idea. I like the shorter version < 
https://www.contributor-covenant.org/version/1/4/code-of-conduct.html >, which 
leaves room for our project to implement various parts as we see fit (the 
PostgreSQL CoC is, in my opinion, a little too specific in some ways such as 
timelines for complaints). Even if we don't have a formal MacPorts conference, 
we are a significant online presence for OSX users and, though (to the best of 
my knowledge) we haven't had significant issues yet that would require a CoC, 
it seems inevitable that something will happen & having the CoC in place allows 
for at least the basics (policies and/or procedures) for handling the 
situation. My US$0.02 ... - MLD

On Tue, Sep 18, 2018, at 11:44 AM, Ryan Schmidt wrote:
> 
> 
> On Sep 18, 2018, at 09:55, Jackson Isaac wrote:
> 
> > Lately, I have seen open source projects have started adopting Code of
> > Conduct. [1], [2]
> > 
> > I think it is a great step to keep the open source community healthy
> > and welcoming to everyone.
> > 
> > I would like to know what other developers think about this. Also, who
> > would be the decision makers (PortMgrs?)
> > 
> > Reference:
> > [1] 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/code-of-conduct.rst
> > [2] https://lwn.net/Articles/765332/
> > 
> > Kind Regards,
> > Jackson Isaac
> 
> Hopefully we've already been a welcoming community so far, but having a 
> code of conduct document doesn't seem like a bad idea.
> 

Re: GitHub PG livecheck failing for release/tags

[Michael Dickens]

OK thanks! - MLD

On Wed, Aug 15, 2018, at 1:51 PM, Christopher Jones wrote:
> 
> https://trac.macports.org/ticket/56975
> 
>> On 15 Aug 2018, at 6:37 pm, Michael Dickens
>>  wrote:>> 
>> At least for me, the GitHub PG livecheck is failing for release/tags
>> ... like, all of them; it is not failing for commits. A quick search
>> on the MP GIT master history shows no changes to the GitHub PG ... so
>> maybe it's just me?  Or maybe GitHub is messing with how it provides
>> tarballs? Can anyone confirm? Thx! - MLD> 
> Email had 1 attachment:


>  * smime.p7s  3k (application/pkcs7-signature)

GitHub PG livecheck failing for release/tags

[Michael Dickens]

At least for me, the GitHub PG livecheck is failing for release/tags ... like, 
all of them; it is not failing for commits. A quick search on the MP GIT master 
history shows no changes to the GitHub PG ... so maybe it's just me?  Or maybe 
GitHub is messing with how it provides tarballs? Can anyone confirm? Thx! - MLD

Re: [macports-ports] branch master updated: grep: add new variant to install as ggrep

[Michael Dickens]

"back in the day" & IIRC: Octave required modern GNU grep to handle locale 
correctly; the built-in grep wasn't guaranteed to do so. That was probably with 
some 3.X series. With the 4.X series maybe it's no longer necessary; IDK. Worth 
testing, IMHO. - MLD

On Sat, Jul 21, 2018, at 7:55 AM, Jan Stary wrote:
> On Jul 21 12:21:55, h...@stare.cz wrote:
> > * math/octave
> >   Depends on GNU grep, GNU sed, and all that.
> > I'll check with math/octave.
> 
> Eh, that would take _days_ on my machine. Not touching that.
> 
> Does anyone now why octave wants GNU grep etc?
> What exactly breaks if it uses the system grep, find, sed, flex?
> 
>   Jan

Re: What "openmaintainer" means

[Michael Dickens]

Great discussion!

My preference for my Openmaintainer ports are probably more conservative / 
controlling than those listed already. For any change except comment fixing and 
rev-bumps due to dependency ABI / API changes, I prefer there to be a PR that I 
can review before committing. I prefer a PR for even minor version updates that 
just change the version & checksums (no patches or other tweaks required), but 
certainly even for missing #include's, adding --disable-werror, or the like.

The reason for my preference is that I'm pretty on top of my ports & I 
test/verify on (currently) 10.5 PPC through 10.13 Intel (actual hardware; not 
just a VM; 10.4 PPC & 10.5 Intel coming soon). Hence I'm very likely to find 
and correct any build issues with my ports (and some others) and provide fixes 
that work across the various OSXs.

When a release update comes out, I'm notified and try to handle it within 24 
hours / I do "devel" updates roughly weekly. Someone else could beat me to the 
update, in which case there can be conflict and my efforts would be wasted 
(which I clearly dislike). A PR would allow me to drop what/if I'm doing & use 
the proposed change, with minimal conflict / waste. Given how easy PRs are in 
git / Github, I see very little downside.

I heartily agree on the 72 hour timeout for any Openmaintainer port, for a 
patch or PR where at least 1 other maintainer beyond the OP has verified the 
change.

Thanks for listening; back to work! - MLD

On Wed, Apr 25, 2018, at 11:33 AM, Ryan Schmidt wrote:
> 
> On Apr 25, 2018, at 10:10, Joshua Root wrote:
> > On 2018-4-26 00:25 , Perry E. Metzger wrote:
> >> On Wed, 25 Apr 2018 04:43:12 +1000 Joshua Root wrote:
> >>> On 2018-4-25 03:56 , Ken Cunningham wrote:
>  Waiting for the maintainer to review the ticket submission
>  someday often resulted in months of nothing happening, or years.  
> >>> 
> >>> The maintainer timeout was 72 hours all along, so that's not really
> >>> relevant to a discussion about the limits of openmaintainer.
> >> 
> >> I think if you don't feel a clean version update falls in the limits
> >> of openmaintainer (that is, just bumping the version and the
> >> checksums), then I'm not sure what does fall under "openmaintainer"
> >> for you.
> > 
> > Minor, uncontroversial changes. Something is broken or suboptimal and
> > the fix is obvious. Specific examples:
> > 
> > * Typos
> > * Using eval when {*} could be used
> > * Rev bump needed when a dependency's ABI changed
> > * Add --disable-werror when the build starts failing when a new version
> > of clang adds a new warning
> > * Fix bundled libtool that thinks 10.10 is 10.1
> > * Build fails on a new OS version because of something like a missing
> > #include
> > * Build is missing the correct -arch flags and adding them in the right
> > place is simple
> 
> I would consider many of those things to be changes that I would make 
> even if the port is not openmaintainer. For example, if I update icu to 
> a new library version, it is my responsibility to revbump all ports 
> linking with icu, regardless of openmaintainer.
> 
> I set openmaintainer in my ports when I don't mind others doing minor 
> changes, including minor updates. This presumes of course that the 
> changes are done correctly. openmaintainer does not mean screw up my 
> ports. Some of my ports are not set to openmaintainer, because they're 
> ports that lots of other ports depend on, and since I've maintained them 
> for awhile, I want to ensure that any proposed changes don't introduce 
> build failures in less-common situations or cause other problems that I 
> may already be aware of but which nonmaintainers might not have 
> considered.
> 
> 
> > Some version bumps may be minor, others are definitely not. I would
> > suggest considering the size of upstream changes in addition to those
> > made to the port.
> 
> 

Re: [macports-ports] 01/04: aften: An A/52 audio encoder

[Michael Dickens]

Agreed! I thought the design was very clever; used some CMake features I never 
knew about. I works for the vast majority of ports ... but not 100% & hence the 
need to options such as the cmake 1.0 PG. - MLD

On Fri, Apr 6, 2018, at 8:36 AM, Ryan Schmidt wrote:
> Ok, I understand. The person who designed the cmake 1.1 portgroup to 
> work that way should explain how they intended this situation to be 
> handled.

Re: [macports-ports] 01/04: aften: An A/52 audio encoder

[Michael Dickens]

The issue being that if a port's configure checks for the build type (e.g., {{{
if(${CMAKE_BUILD_TYPE} STREQUAL "Release") then
...
elseif
}}}
and so forth, and if "MacPorts" is not in BUILD_TYPEs list -- no matter whether 
it has settings available for use by CMake already --, then cmake errors out. 
See, e.g., < 
https://github.com/gnuradio/gnuradio/blob/master/cmake/Modules/GrBuildTypes.cmake
 >. Yes, I know I can always add "MacPorts" to the list and/or tweak the 
CMAKE_BUILD_TYPE in the portfile to be something acceptable. Again: That takes 
(a little) work and testing /debugging to make sure it's correct. It also 
removes some of the point of updating to cmake 1.1 PG: to simplify Portfiles 
and add MP-specific options for building. Although the cmake 1.0 PG works out 
of the for my ports (per design), I will update those ports that don't check 
for the BUILD_TYPE to the 1.1 PG as I find time. I'm not sure what I'll do with 
my ports that do check the BUILD_TYPE. - MLD

On Fri, Apr 6, 2018, at 8:21 AM, Ryan Schmidt wrote:
> The fact that the cmake 1.1 portgroup uses build type "MacPorts", not 
> "Release", is meant to be a feature, not a bug:
> 
> https://trac.macports.org/ticket/52699#comment:1
> 
> > • use CMAKE_BUILD_TYPE=MacPorts. Inspired by Debian's own build type, this 
> > allows us to specify all compiler settings via the well-known configure.* 
> > commands and exported via the environment. If one of CMake's predefined 
> > types is used the corresponding standard options will be *appended* to our 
> > options, which will override notably the optimisation options. Some parsing 
> > of configure.cppflags, configure.cflags and configure.cxxflags is done to 
> > ensure this works as expected, in lines 145-200 .

Re: [macports-ports] branch master updated: gnuradio*: rev-bump for updated Jack ABI.

[Michael Dickens]

If you use otool for the self-id on the resulting libraries you'll see that the 
old jack ("0.124.1_2") produced:
{{{
/opt/local/lib/libjack.0.dylib (compatibility version 1.0.0, current 
version 1.28.0)
}}}
while the new one ("1.9.12_0") shows:
{{{
/opt/local/lib/libjack.0.dylib (compatibility version 0.0.0, current 
version 0.1.0)
}}}
So either the ABI has changed or the "new" jack's library version creation 
settings are incorrect. Either way, a rev-bump fixes the issue & makes "port 
rev-upgrade" happy too ;) I do think that the Jack API and ABI are actually 
upgrade-compatible beyond the internal versioning issue listed here. - MLD

On Fri, Apr 6, 2018, at 8:13 AM, Ryan Schmidt wrote:
> 
> On Apr 6, 2018, at 06:49, Michael Dickens wrote:
> 
> > Michael Dickens (michaelld) pushed a commit to branch master
> > in repository macports-ports.
> > 
> > 
> > https://github.com/macports/macports-ports/commit/398bdaad2d3e7c6f0af1cf92658f6d06f9e33971
> > 
> > The following commit(s) were added to refs/heads/master by this push:
> > 
> >  new 398bdaa  gnuradio*: rev-bump for updated Jack ABI.
> > 
> > 398bdaa is described below
> > 
> > 
> > commit 398bdaad2d3e7c6f0af1cf92658f6d06f9e33971
> > 
> > Author: Michael Dickens
> > AuthorDate: Fri Apr 6 07:49:32 2018 -0400
> > 
> > 
> > gnuradio*: rev-bump for updated Jack ABI.
> 
> Did you notice a problem before this rebuild? The new Jack was thought 
> to be compatible with the old Jack, which is why revbumps weren't done. 
> If that's not so, then we may need to revbump anything else that links 
> with Jack.
> 

Re: [macports-ports] 01/04: aften: An A/52 audio encoder

[Michael Dickens]

My primary reason for not moving to cmake 1.1 in the various GR & other ports I 
use is that it sets the default build type to "MacPorts", which has no real 
meaning & actually conflicts with some of my ports' cmake scripts & so I have 
to work around that (which isn't difficult; just takes time and testing). 
Otherwise I find that for my ports they seem to provide roughly the same 
outcome (same cmake commandline). If the default build type were "Release" I'd 
have no issue switching right now & it would simplify my ports that use cmake 
1.0. - MLD

On Fri, Apr 6, 2018, at 3:52 AM, Ryan Schmidt wrote:
> 
> On Apr 6, 2018, at 02:48, Clemens Lang wrote:
> 
> > On 6 Apr, 2018, at 08:03, Ryan Schmidt wrote:
> > 
> >> jack conflicts with jack?
> > 
> > Thanks, remnant from my attempts to package jack and jack2 in separate 
> > ports.
> > Fixed in 678e0100a4c07d55750e6dc667492dc26cdab208.
> > 
> >> On Apr 5, 2018, at 18:18, Clemens Lang wrote:
> >>> +PortGroup   cmake 1.0
> >> 
> >>> +cmake.out_of_source yes
> >> 
> >> We should be using the cmake 1.1 portgroup for new ports, and moving old 
> >> ports
> >> that use cmake 1.0 to 1.1 as time permits. cmake 1.1 defaults to 
> >> out-of-source
> >> builds, and has other improvements over cmake 1.0.
> > 
> > I'm not convinced the changes in cmake 1.1 are actually an improvement over 
> > the
> > state of the cmake 1.0 portgroup. What do you think the improvements are?
> 
> Well I don't know. It defaults to out-of-source builds adds options for 
> configuring some values, both of which are good, and it has support for 
> generators which I don't know anything about, and probably some other 
> changes. Here's the ticket describing 1.1's creation:
> 
> https://trac.macports.org/ticket/52699
> 

Re: [macports-ports] branch master updated: rtl-sdr: move to GitHub PG.

[Michael Dickens]

Good catch. I had forgot to do the --no-mirror & everything seemed OK. Fixed in 
https://github.com/macports/macports-ports/commit/c4e604e95d59245727f39dc4495f653988e9d3f4
 . - MLD

On Sun, Apr 1, 2018, at 4:00 PM, Ryan Schmidt wrote:
> 
> On Apr 1, 2018, at 13:47, Michael Dickens wrote:
> 
> > Michael Dickens (michaelld) pushed a commit to branch master
> > in repository macports-ports.
> > 
> > 
> > https://github.com/macports/macports-ports/commit/ed3f300c45bd2743297590cf8aa96b27bf8816dd
> > 
> > The following commit(s) were added to refs/heads/master by this push:
> > 
> >  new ed3f300c rtl-sdr: move to GitHub PG.
> > 
> > ed3f300c is described below
> > 
> > 
> > commit ed3f300c45bd2743297590cf8aa96b27bf8816dd
> > 
> > Author: Michael Dickens <michae...@macports.org>
> > AuthorDate: Sun Apr 1 14:47:23 2018 -0400
> > 
> > 
> > rtl-sdr: move to GitHub PG.
> > 
> > ---
> >  science/rtl-sdr/Portfile | 21 +
> >  1 file changed, 9 insertions(+), 12 deletions(-)
> > 
> > 
> > diff --git a/science/rtl-sdr/Portfile b/science/rtl-sdr/Portfile
> > index 7c98012..2a0d546 100644
> > --- a/science/rtl-sdr/Portfile
> > +++ b/science/rtl-sdr/Portfile
> > @@ -2,8 +2,17 @@
> >  
> >  PortSystem  1.0
> >  PortGroup   cmake 1.0
> > +PortGroup   github 1.0
> >  
> >  namertl-sdr
> > +maintainers {michaelld @michaelld} openmaintainer
> > +
> > +github.setuposmocom rtl-sdr 
> > 4520f001d85f01d051eaa42af7b18b6ef0837e14
> > +version 20180220
> > +checksums   rmd160 80c9c38d8d9b6d747ac4a18f105fa388f8987ed2 \
> > +sha256 
> > a46c9bd6b9c5391b01101dbdfe992ac78cbf038eb07c423091a73915c8db268b \
> > +size   119913
> > +
> >  categories  science comms
> >  platforms   darwin
> >  license GPL-2
> > @@ -12,14 +21,6 @@ description ${name} allows using devices with a 
> > RTL2832U chipset as soft
> >  long_description${description}
> >  homepagehttp://sdr.osmocom.org/trac/wiki/rtl-sdr
> >  
> > -set commit  4520f001d85f01d051eaa42af7b18b6ef0837e14
> > -version 20180220
> > -checksums   rmd160 80c9c38d8d9b6d747ac4a18f105fa388f8987ed2 \
> > -sha256 
> > a46c9bd6b9c5391b01101dbdfe992ac78cbf038eb07c423091a73915c8db268b
> > -
> > -distname${name}-${commit}
> > -master_siteshttp://cgit.osmocom.org/rtl-sdr/snapshot/
> 
> You've performed a stealth-update, which changes the checksums:
> 
> 
> $ sudo port fetch --no-mirror rtl-sdr
> --->  Fetching distfiles for rtl-sdr
> --->  Attempting to fetch rtl-
> sdr-4520f001d85f01d051eaa42af7b18b6ef0837e14.tar.gz from 
> https://github.com/osmocom/rtl-sdr/tarball/4520f001d85f01d051eaa42af7b18b6ef0837e14
> $ sudo port checksum rtl-sdr 
> --->  Verifying checksums for rtl-sdr
> Error: Checksum (rmd160) mismatch for rtl-
> sdr-4520f001d85f01d051eaa42af7b18b6ef0837e14.tar.gz
> Error: Checksum (sha256) mismatch for rtl-
> sdr-4520f001d85f01d051eaa42af7b18b6ef0837e14.tar.gz
> Error: Checksum (size) mismatch for rtl-
> sdr-4520f001d85f01d051eaa42af7b18b6ef0837e14.tar.gz
> Error: Failed to checksum rtl-sdr: Unable to verify file checksums
> Error: See /opt/local/var/macports/logs/
> _Users_rschmidt_macports_macports-ports-svn-trunk_science_rtl-sdr/rtl-
> sdr/main.log for details.
> Error: Follow https://guide.macports.org/#project.tickets to report a 
> bug.
> Error: Processing of port rtl-sdr failed
> rschmidt@Untitled-Mac rtl-sdr $ 
> 
> 
> See: https://trac.macports.org/wiki/PortfileRecipes#stealth-updates
> 
> 
> Switching a port from other hosting to GitHub is simpler if you combine 
> it with a version update, since the distname and checksums will change 
> anyway.
> 

Re: [macports-ports] branch master updated: inspectrum: new port

[Michael Dickens]

OK; guess I didn't follow the cmake 1.1 discussion (somehow).

So for current ports that use cmake 1.0, updating looks to involve 2 parts:

1) "1.0" -> "1.1"
2) remove the "cmake.out_of_source yes" line and comment.

Initial testing looks like that's all I need to do. Does that sound correct? - 
MLD

On Wed, Mar 21, 2018, at 6:33 PM, Ryan Schmidt wrote:
> On Mar 21, 2018, at 16:46, Michael Dickens wrote:
> > +PortGroup   cmake 1.0
> 
> > +# do VPATH (out of source tree) build
> > +
> > +cmake.out_of_source yes
> 
> New ports (and old ports, as time permits) should use the cmake 1.1 
> portgroup instead of the cmake 1.0 portgroup. cmake 1.1 defaults to out 
> of source builds, and has other improvements.

Re: [macports-ports] branch master updated: qt4-mac: fix typo

[Michael Dickens]

Good catch. Reverted. - MLD

On Sun, Mar 11, 2018, at 12:56 AM, Ryan Schmidt wrote:
> 
> On Feb 28, 2018, at 14:15, Michael Dickens wrote:
> 
> > Michael Dickens (michaelld) pushed a commit to branch master
> > in repository macports-ports.
> > 
> > 
> > https://github.com/macports/macports-ports/commit/1c1ac943702a9978c9201f356d7095bd30c0e383
> > 
> > The following commit(s) were added to refs/heads/master by this push:
> > 
> >  new 1c1ac94  qt4-mac: fix typo
> > 
> > 1c1ac94 is described below
> > 
> > 
> > commit 1c1ac943702a9978c9201f356d7095bd30c0e383
> > 
> > Author: Michael Dickens
> > AuthorDate: Wed Feb 28 15:15:21 2018 -0500
> > 
> > 
> > qt4-mac: fix typo
> > 
> > ---
> >  aqua/qt4-mac/Portfile | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > 
> > diff --git a/aqua/qt4-mac/Portfile b/aqua/qt4-mac/Portfile
> > index 3f71c91..f72549f 100644
> > --- a/aqua/qt4-mac/Portfile
> > +++ b/aqua/qt4-mac/Portfile
> > @@ -342,7 +342,7 @@ if {${SDK} eq ""} {
> >  post-patch {
> >  # set ARCHES in configure (per the third patchfile above), for
> >  # building QMake.  join any 2 or more arch entries with the GCC
> > -# arch flag (join does not affect a single entry).  first "-arch"
> > +# arch flag (join does not effect a single entry).  first "-arch"
> >  # is already in place in the 'configure' script (since there has
> >  # to be at least 1 arch).
> 
> Actually it was correct before. :) I had previously fixed this typo:
> 
> https://github.com/macports/macports-ports/commit/ff90bcc0d6678ede80f1fa69a28840b6776d7d8c
> 

Re: request for port create command, to build a portfile from a URL

[Michael Dickens]

Hi Ken - I think that's a great idea. In "GNU Radio" land, we have such a tool 
for creating out-of-tree GR modules, called "gr_modtool"; it's great for 
setting up the skeleton for such OOT GR scripts. The end-user still has to fill 
in many "blanks", but this tool provides the starting point. I could see 
something similar for MacPorts, much as you describe. Maybe this could be added 
to the GSoC wiki page? It shouldn't be too difficult to implement something 
like what you propose, whether directly in 'port' or as a tool separate from 
'port'. Cheers! - MLD

On Tue, Mar 6, 2018, at 9:58 AM, Ken Cunningham wrote:
> It would be nice to have a command like
> 
> port create URL
> 
> that would download the URL, calc the checksums for it, and build a 
> basic Portfile for it.
> 
> It could ask for a category to use for the Port.
> 
> In a more advance version, it could extract the URL and do some quick 
> analysis on it.
> 
> if there's a CMakeLists.txt file in the root, do the right things to 
> make it a cmake based port.
> 
> If there's a configure file in the root, do the right things for that.
> 
> Might make things faster and easier for people to get started and up and 
> running.
> 
> Certainly would make it easier for people who want to use MacPorts 
> infrastructure to build their own files, as many don't know how to 
> properly set up the include and lib directories, etc.

Re: sizeof(long) and universal builds

[Michael Dickens]

Since the port is using GNU Autotools, AC_COMPILE_CHECK_SIZEOF will return one 
of 2 values depending on which -arch flag is used / set / set first / some 
random reason; it cannot return both values. Hence why using muniversal if 
truly in doubt.

The best solution is to use pre-sized types such as uint64_t or the like. 
There's just no good reason to need sizeof(long) unless it is used to set 
things such as uint64_t ...

... which is exactly what zziplib seems to do; see also:
* < https://github.com/gdraheim/zziplib/search?q=ZZIP_SIZEOF_SHORT >
* < https://github.com/gdraheim/zziplib/search?q=ZZIP_SIZEOF_INT >
* < https://github.com/gdraheim/zziplib/search?q=ZZIP_SIZEOF_LONG >
which all point (for Darwin) to this file:
< https://github.com/gdraheim/zziplib/blob/master/zzip/stdint.h >
which tries to define "uint*_t" and "int*_t".

This file includes, in this order, the first available of:
{{{
#include 
-or-
#include 
-or-
#include 
}}}
before using the ZZIP_SIZEOF_LONG (etc). Since at least one of these #includes 
is available on all Darwin, the *_SIZEOF_* aren't even used. Not the best 
configure.ac programming, IMHO.

I'm guessing that zziplib uses the uint*_t & int*_t internally, which if so 
then it's safe to use +universal for this port without using muniversal or any 
special trickery.

Hope this helps! - MLD

On Thu, Mar 1, 2018, at 4:27 PM, Mojca Miklavec wrote:
> On 1 March 2018 at 20:42, Michael Dickens wrote:
> > In the past, I've handled this situation by using the muniversal PortGroup, 
> > so that the sizeof is correct for each build independent of the other. - MLD
> 
> I'm aware of that. I was wondering if there was some *proper* solution
> that could allow compiling just once.
> 
> Mojca
> 
> > On Thu, Mar 1, 2018, at 2:40 PM, Mojca Miklavec wrote:
> >> While checking some patches of a library I decided to try whether the
> >> library would build universally. The configure.ac part contains:
> >>
> >> AC_COMPILE_CHECK_SIZEOF([long])
> >>
> >> and that happily fails with
> >>
> >> checking size of long... configure: error: cannot determine a size for 
> >> long
> >>
> >> when setting
> >>
> >> CXXFLAGS="-arch i386 -arch x86_64"
> >>
> >> What's the correct way to handle universal builds in that respect? Or
> >> is it that is simply cannot be done?
> >>
> >> Thank you,
> >> Mojca
> >>
> >>
> >> PS: here's the relevant commit:
> >> https://github.com/gdraheim/zziplib/commit/75ddc796529b191437514be2bbf6a2f561a74a6f

Re: sizeof(long) and universal builds

[Michael Dickens]

In the past, I've handled this situation by using the muniversal PortGroup, so 
that the sizeof is correct for each build independent of the other. - MLD

On Thu, Mar 1, 2018, at 2:40 PM, Mojca Miklavec wrote:
> While checking some patches of a library I decided to try whether the
> library would build universally. The configure.ac part contains:
> 
> AC_COMPILE_CHECK_SIZEOF([long])
> 
> and that happily fails with
> 
> checking size of long... configure: error: cannot determine a size for 
> long
> 
> when setting
> 
> CXXFLAGS="-arch i386 -arch x86_64"
> 
> What's the correct way to handle universal builds in that respect? Or
> is it that is simply cannot be done?
> 
> Thank you,
> Mojca
> 
> 
> PS: here's the relevant commit:
> https://github.com/gdraheim/zziplib/commit/75ddc796529b191437514be2bbf6a2f561a74a6f

Boost / NumPy / libpsl Cyclic Dependency Fix Option

[Michael Dickens]

Hi David (& MacPorts developers) - Yesterday, py*-numpy was added as a 
dependency of Boost (in order to make sure boost.numpy is built knowingly), 
which created a cyclic dependency: boost -> py27-numpy -> gcc7 -> cctools -> 
llvm-5.0 -> cmake -> curl -> libpsl -> gtk-doc -> source-highlight -> boost. 
The obvious places to create a subport are in boost (boost-numpy) and libpsl 
(libpsl-docs). Neither boost nor libpsl allows building just the subport parts; 
we have to build the whole port then discard the extra cruft. The greater 
discussion is documented in < https://trac.macports.org/ticket/55807 >, and I 
added you on CC yesterday as well as am writing this email top the greater 
MacPorts developers group. I added an attachment patch that creates the subport 
libpsl-docs in the libpsl Portfile, and it works nicely for me on my various 
test computers & I hope others try it out as well & give feedback. Given that 
it takes maybe a minute or 2 max to build libpsl -- as opposed to many minutes 
to build Boost -- I'm inclined to push my libpsl-docs subport as a quick fix to 
the problem. We can then work on a better solution if folks wish to do so. 
Although the libpsl port is openmaintainer, this is a significant change so I'd 
value your feedback on how to proceed -- as well as feedback from the greater 
MacPorts developer community. Thanks! - MLD

Re: [macports-ports] branch master updated: SDRplay: fix livecheck.

[Michael Dickens]

Ah; got it. Yeah OK I see the issue. I'll fix that thx! - MLD

On Tue, Jan 30, 2018, at 11:46 AM, Ryan Schmidt wrote:
> What I mean is that your livecheck.regex specifically mentions version 
> 2.11. If the project ever releases version 2.12, for example, the 
> livecheck will no longer match.

Re: [macports-ports] branch master updated: SDRplay: fix livecheck.

[Michael Dickens]

On Tue, Jan 30, 2018, at 11:08 AM, Ryan Schmidt wrote:
> 
> On Jan 30, 2018, at 08:25, Michael Dickens wrote:
> 
> > Michael Dickens (michaelld) pushed a commit to branch master
> > in repository macports-ports.
> > 
> > 
> > https://github.com/macports/macports-ports/commit/0ddb648a6972bbde95b3708b7de8847a9dcef14e
> > 
> > The following commit(s) were added to refs/heads/master by this push:
> > 
> >  new 0ddb648  SDRplay: fix livecheck.
> > 
> > 0ddb648 is described below
> > 
> > 
> > commit 0ddb648a6972bbde95b3708b7de8847a9dcef14e
> > 
> > Author: Michael Dickens
> > AuthorDate: Tue Jan 30 09:25:31 2018 -0500
> > 
> > SDRplay: fix livecheck.
> > 
> > Will now show that an update happened, not the actual new version. 
> > There's no way to determine that information from their website without 
> > actually downloading the file -- which is behind a reCAPTCHA.
> > 
> > ---
> >  science/SDRplay/Portfile | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/science/SDRplay/Portfile b/science/SDRplay/Portfile
> > index 82fb5b5..b29b345 100644
> > --- a/science/SDRplay/Portfile
> > +++ b/science/SDRplay/Portfile
> > @@ -86,4 +86,5 @@ destroot {
> >  }
> >  
> >  livecheck.url   http://www.sdrplay.com/downloads/
> > -livecheck.regex macdl.php.>API/HW Driver.*v(\[0-9.\]+)
> > +livecheck.version   15th Nov 2017
> > +livecheck.regex {API/HW Driver  v2.11 
> > \((.*)\)}
> 
> The version number will always be 2.11?
> 

No, the livecheck version is the date. It used to be that the version worked, 
but that's not the case any longer. The latest version is actually 2.11.2, so 
comparing with the embedded version (2.11) doesn't work. The date should work 
though. - MLD

Re: help with generating a diff with svn for libcxx

[Michael Dickens]

Guessing that you've run into a local permissions issue. This happens
with any repo manager: if it can't access a required file, it can't do
squat! I regularly do "chmod -R u+rw ." from the top level of my local
repos to make sure at least -I- can access all of the files. That said,
glad you found a way around the issue. Cheers! - MLD

On Sun, Dec 3, 2017, at 03:35 PM, Ken Cunningham wrote:
> I decided to just page back in time over and over through the github
> interface until I found the commit that way, and generated the diff by
> adding ".diff" on the end of the URL. Not the right way to do it, I know
> -- but it worked.
> 
> 
> 
> Happy to learn the " right way" when anyone has time.
> 
> Thanks,
> 
> K
> 
> 
> On 2017-12-03, at 12:28 PM, Ken Cunningham wrote:
> 
> > I'm getting stuck generating a diff file for the changes made in revison 
> > 307461 of libcxx, so I can backport that into llvm-4.0 to fix the build of 
> > libcxx for PowerPC.
> > 
> > 
> > 
> > I have checked out the llvm, libcxx, and libcxxabi sources using svn.
> > In the projects/libcxx directory, I tried
> > 
> > svn diff -r 307460:307461
> > but that gives me "svn: E175013: Access to 
> > '/svn/llvm-project/!svn/vcc/default' forbidden"
> > 
> > so I've tried
> > 
> > svn diff -r 307460:307461 http://llvm.org/svn/llvm-project/libcxx/trunk
> > svn diff -r 307460:307461 http://llvm.org/svn/llvm-project/libcxx/trunk .
> > svn diff -r http://llvm.org/svn/llvm-project/libcxx/trunk@307460 
> > http://llvm.org/svn/llvm-project/libcxx/trunk@307461
> > 
> > but that all gives a similar error.
> > 
> > I know this must be easy, otherwise nobody would be using svn.
> > 
> > I thought about using the github sources, but finding svn revision 307461 
> > for libcxx in github is not simple either.
> > 
> > Open to ideas.
> > 
> > Thanks,
> > 
> > Ken
> 

Re: [macports-ports] branch master updated: cmake: require C++11 for both release and devel.

[Michael Dickens]

Reverted in <
https://github.com/macports/macports-ports/commit/44373e0fd9955702e9e2f6820b2cf595fec24c65
>. Thanks for testing & feedback. If/when the release is moved to
requiring C++11, I'll also create a subport for the last version that
doesn't, for bootstrap purposes per our discussion (assuming it is still
relevant to do so at that time). - MLD

On Mon, Nov 6, 2017, at 10:45 PM, Ryan Schmidt wrote:
> 
> On Nov 6, 2017, at 21:40, Ryan Schmidt wrote:
> 
> > On Nov 6, 2017, at 21:34, Ken Cunningham wrote:
> > 
> >> On 2017-11-06, at 7:13 PM, Ryan Schmidt wrote:
> >> 
> >>> Wow, this really sucks. It means that on Mountain Lion and earlier, cmake 
> >>> now depends on clang-5.0, clang-4.0, clang-3.9, clang-3.8, and clang-3.7, 
> >>> and on Lion and earlier, also clang-3.4. It also says all compilers are 
> >>> blacklisted so I'm not sure if it builds. Judging by the fact that binary 
> >>> packages were only produced for Mavericks and later, I'm guessing it does 
> >>> not build on earlier systems.
> >> 
> >> 
> >> Yeah, Mike and I had a little chat about that a few weeks ago when this 
> >> came through.
> > 
> > Yes I just saw your comments on GitHub:
> > 
> > https://github.com/macports/macports-ports/commit/c8d94a92cb1d690a3dc052ff1ed7c0107af9b32a
> > 
> > 
> >> This is presently a bootstrap issue for new installs on older systems. The 
> >> c++11 requirement is right in the kitware commits, so that looks like a 
> >> real deal. 
> >> .
> > 
> > I know cmake master requires C++11. What I'm saying is that I don't think 
> > 3.9.5 requires C++11. I'm checking on that now.
> 
> Yup, 3.9.5 builds fine with libstdc++.
> c8d94a92cb1d690a3dc052ff1ed7c0107af9b32a should be reverted.

Re: how to efficiently work through generating patches using git and macports build process?

[Michael Dickens]

You can always create or add them to a .gitignore file. If at the top-
level GIT repo, this file impacts the whole repo. You would literally
add "*.o" (but without the ""s) to this file to ignore all *.o files.
Just be careful to not ignore port-original files.
Example of how I do it; slightly different than Mojca's:
{{{
sudo port extract gr-ofdm
pushd $(port work gr-ofdm)
sudo chmod -R a+rw .
cd gr-ofdm
git init
git add -A
git commit "init" > /dev/null
}}}

Then, go about editing & any change will easily be found via "git
status". You can also revert back to the "init" (or last commit) version
of a file via "git checkout -- [filename]". Getting the changes is easy,
via "git diff" ... but note that this diff is "patch -p1" style, not the
usual MacPorts "patch -p0" style. It's easy to convert between them, but
will generally be a pain if a lot of files have been changed. My git-foo
isn't very strong, but these I know & they work quite well for fixing
MacPorts ports via source.
Using the above, to get back to the directory where you were, just
do "popd".
Another benefit to the "chmod" at the top-level "work" directory is that
you can then edit the ".macports.*.state" file -- e.g., to revert the
state back to "patched" so-as to force configuration again. Or you can
remove the build or destroot directory without having to "sudo"; ditto
for file editing.
Hope this helps! - MLD

On Wed, Aug 30, 2017, at 12:50 PM, Ken Cunningham wrote:
> 
> On 2017-08-30, at 9:41 AM, Michael Dickens wrote:
> 
>> What Mojca wrote is what I do too. Simple but very effective! - MLD
>> 
> 
> Is there a way to make git ignore the *.o and *.a and other generated
> files that might be in the source tree that we're not interested in
> tracking -- or does the -A do that automatically?

Re: how to efficiently work through generating patches using git and macports build process?

[Michael Dickens]

Hi Ken - I, for one, would strongly encourage you to use the GIT process
you mention. You still have to be careful to distinguish between
patchfiles and reinplace patches, but hopefully that's not too
difficult. Another benefit to using GIT is that if you messed up a fix,
you can always revert it & start it from the original file.

Didn't we have a set of "shortcuts" that included the commands for
setting up the local GIT repo? Might be worthwhile for folks with such
shortcuts to push a link to this list (again). - MLD

On Wed, Aug 30, 2017, at 11:44 AM, Ken Cunningham wrote:
> I'm looking to improve my efficiency.
> 
> When trying to fix broken ports, I have so far been using the method of
> copying the source file to source.orig, editing the source files in
> place, and then noting the files I worked on, to individually diff them
> at the end to individual patch files.
> 
> It's easy to understand, but not super efficient, especially when I make
> a number of changes in different files.
> 
> Using macports build process, is there a more efficient way that people
> use, perhaps using git branches in the worksrcdir?
> 
> Something like - 
> 
> sudo port -v extract PORTNAME
> 
> then make a git branch in the worksrcdir and check it out
> 
> then
> 
> `sudo port -v build PORTNAME` or perhaps `sudo port -v destroot PORTNAME`
> 
> and  keep plugging away with edits until it builds to completion
> 
> and in the end, just git diff the whole worksrcdir folder?
> 
> 
> Best,
> 
> Ken

Re: combining directories / moving files within Portfile

[Michael Dickens]

On Thu, Jul 20, 2017, at 10:46 AM, Rainer Müller wrote:
> On 2017-07-19 23:09, Michael Dickens wrote:
> > I have an issue with SIP that needs to be addressed, that I'm not sure
> > how do execute in port via Portfiles. I have a solution, but it's kinda
> > a hack.
> 
> This confused me a lot as I first assumed you are talking about
> System Integrity Protection... :-)

LOL

> > My Hack
> > ---
> > My "hack" is to have SIP check in pre-activate for the directory
> > "$prefix/share/pyXY-sip/" and if found then create an archive of its
> > contents (into /tmp/something.tar), and "cd $prefix/share && rm -rf
> > pyXY-sip". Then the 'activate' takes place, which creates the symlink to
> > the "$PYTHON_PREFIX/share/sip/$subport" directory. Then in post-activate
> > check for the archive & if found restore the contents into the directory
> > "$PYTHON_PREFIX/share/sip/" && remove the archive.
> 
> These files would no longer be properly attributed to the port in the
> registry, so they might be left behind on uninstall.

The registry seemed OK with the move, since port follows links correctly
for installing or removing files. That said, I can't do "port provides
..." on any of those files any longer, but I don't care since they will
be dealt with via their port upgrades anyway.

> It sounds like you need the deactivate hack that is already in use for
> some ports that needed to replace files:
> https://trac.macports.org/wiki/PortfileRecipes#deactivatehack
> 
> I would deactivate all ports known to install files there in a
> pre-activate phase in the main sip port.

Yes! That's the trick.

Instead of deactivating all ports known to install files there, is there
a way to query the registry for which port owns the files present (e.g.,
"port provides ..." except in TCL registry function calls)? - MLD

Re: Qmake does not respect compiler choice

[Michael Dickens]

Hi Nicolas - qmake by itself will not "do the right thing", as you note,
for pretty much any 'port' setting (CC, CXX, *FLAGS).
If you use the qmake 1.0 PortGroup, then qmake should "do the right
thing". If you're using this PG & qmake is still not doing the right
thing, then the issue is likely the 'Makefile' or 'configure' script
interface.
Hope this helps! - MLD

On Sat, Jul 1, 2017, at 08:07 AM, Nicolas Pavillon wrote:
> While trying to solve an issue where one of my ports does not respect
> the compiler choice (ticket #54372, thanks Ryan for pointing that
> out), I realised that qmake seems to not be respecting the choice of
> compiler in any case.> On Mac, qmake uses by default the 'macx-g++’ 
> configuration, which sets
> everything to use clang, regardless of the choice of compiler,
> including flags such as Xarch which are not compatible with gcc. I
> could reproduce that problem with both mine and other ports.> I noticed that 
> qmake also has config files for instance for gcc 4.2
> (macx-g++42) or llvm (macx-llvm), but I did not yet confirm if those
> could be used.> 
> I assume that the PortGroup would have to be modified to properly
> choose the config file depending on the chosen compiler (which I could
> try to implement), but I wanted to check first if someone already
> solved that issue, or if I am missing something obvious.

Re: gcc & libgcc 6/7/8

[Michael Dickens]

Back on-list again:

As noted by Ryan, GCC6 and prior use libgcc from GCC6. There
is(are) ABI change(s) in libgcc from GCC6 to GCC7 (e.g., some
different compatibility versions for libraries; some different
symbols in libraries; some different version in filenames). I don't
know about GCC8 yet.
Thus, moving to the current libgcc-devel (GCC7) from libgcc (GCC6)
requires rebuilding all dependent ports, which for me is about 11 ports
& most are pretty quick to rebuild.
Given that Ryan is on top of this, I'll defer to him. I'm happy to
help out, but I'll not update GCC7 any longer (to snapshots or the
latest release).
Cheers! - MLD

On Thu, Jun 29, 2017, at 06:03 PM, Chris Jones wrote:
> On 29 Jun 2017, at 10:48 pm, Ken Cunningham
> <ken.cunningham.web...@gmail.com> wrote:>> The plan in the libgcc Portfile 
> says to keep moving libgcc along
>> until there is an incompatible ABI change, and then when that
>> happens, spin off the last compatible version as a separate port
>> (like this one libgcc45 @4.5.4_12 (lang)) to support all the gcc
>> versions that can't move past that version of libgcc,  and then move
>> the rest along.>> 
>> So long as gcc 5 / 6 are compatible with libgcc 7 or even libgcc 8 ,
>> should be no problem.>> 
>> To install libgcc-devel you need to uninstall or deactivate libgcc
>> first, of course, as they overwrite each other's files.> 
> Yes, of course, i understand this. My point was really unless there is
> a reason not to the default libgcc port should be  kept up to date
> with the latest stable release, which is as of now gcc7.  I have no
> interest to work with a real devel release, so have no plans to update
> my libgcc port to libgcc-devel.> 
> Chris
> 
>> 
>> At some point, bootstrapping gets to be a concern.
>> 
>> K
>> On 2017-06-29, at 1:16 PM, Christopher Jones wrote:
>> 
>>> Hi,
>>> 
>>> In my opinion libgcc should be based on the latest stable gcc
>>> release, which is now gcc7. Right now, if I try and install gcc
>>> 7 I get>>> 
>>>> Oberon ~ > sudo port install gcc7
>>>> Portfile changed since last build; discarding previous state.
>>>> --->  Computing dependencies for gcc7
>>>> Error: Can't install libgcc-devel because conflicting ports are
>>>> active: libgcc>>>> Error: Follow 
>>>> https://guide.macports.org/#project.tickets to report
>>>> a bug.>>>> Error: Processing of port gcc7 failed
>>> 
>>> which in my opinion should be resolved.
>>> 
>>> Chris
>>> 
>>>> On 29 Jun 2017, at 8:49 pm, Michael Dickens
>>>> <michae...@macports.org> wrote:>>>> 
>>>> I recently noticed that gcc7 had an update, and so I've started
>>>> updating>>>> it. I'll move it to the 7.1 release shortly. There's also a
>>>> new gcc8>>>> snapshot that I'll look into getting up for folks on the
>>>> bleeding edge>>>> to try out (as I'm often asked to do for UHD / Volk / 
>>>> GNU Radio).
>>>> 
>>>> The question comes up as to what version "libgcc" should be.
>>>> Right now>>>> libgcc is a subport of gcc6. gcc7 requires an updated 
>>>> version of
>>>> libgcc,>>>> as I'm guessing gcc8 does.
>>>> 
>>>> I can easily leave libgcc attached to gcc6, and then disable
>>>> libgcc-devel in favor of libgcc7 and libgcc8 ... but, I'm pretty
>>>> new at>>>> the gcc / libgcc combo so I'm really not sure what the best or
>>>> proper>>>> way to go here is.
>>>> 
>>>> Looking for thoughts and direction on how to proceed. Thx! - MLD

gcc & libgcc 6/7/8

[Michael Dickens]

I recently noticed that gcc7 had an update, and so I've started updating
it. I'll move it to the 7.1 release shortly. There's also a new gcc8
snapshot that I'll look into getting up for folks on the bleeding edge
to try out (as I'm often asked to do for UHD / Volk / GNU Radio).

The question comes up as to what version "libgcc" should be. Right now
libgcc is a subport of gcc6. gcc7 requires an updated version of libgcc,
as I'm guessing gcc8 does.

I can easily leave libgcc attached to gcc6, and then disable
libgcc-devel in favor of libgcc7 and libgcc8 ... but, I'm pretty new at
the gcc / libgcc combo so I'm really not sure what the best or proper
way to go here is.

Looking for thoughts and direction on how to proceed. Thx! - MLD

Re: c++ library usage

[Michael Dickens]

Understood and agreed, Mojca. Again: It seems like keeping track of the
std c++ lib could be done by port & would have utility (mostly for
developers, but still). It would certainly beat adding compiler variants
to all C++ ports to get the c++ lib correct for dependents (as I did for
my test for GR). No, I don't expect this to happen overnight; it's a
process, but it's one that will keep popping up here and there (as per
this email). It's good to get confirmation that it's not just me, too :)
Thx! - MLD

On Wed, Jun 21, 2017, at 09:52 AM, Mojca Miklavec wrote:
> On 21 June 2017 at 03:48, Michael Dickens wrote:
> > Hi MP devs - A hopefully brief discussion of / query about c++ library
> > usage, with a little background. What I describe below works for me,
> > which makes me wonder if what I'm doing is nonstandard use of 'port' or
> > what's going on ...
> >
> > GNU Radio devs were asked whether GR compiles using GCC7 cleanly, so I
> > decided to give it a try on my macOS setup (10.12 most recent of
> > everything running on a MacBook Pro Retina Touchpad; standard MacPorts
> > install from GIT). Installing GCC7 was pretty simple, but of course GR
> > didn't link because some of its dependencies were not built using
> > libstdc++ from libgcc-devel, so the C++ library wasn't correct & mixing
> > C++ libraries doesn't generally work anyway.
> >
> > Adding some temporary code to the Portfiles of those dependencies
> > allowed me to install them with compiler variants, which did the trick &
> > GR built cleanly & even passes "make test". The dependencies also work,
> > even though they are linked to libgcc-devel's libstdc++; they do not use
> > libc++ -- directly or indirectly from the look of it. Thus, I was able
> > to pretty quickly report back that GR is, or will be shortly when I get
> > some pull requests in place, compatible with GCC7. There are plenty of
> > deprecation warnings, but we can ignore those for now.
> >
> > The above got me thinking about c++ library linking and usage, because
> > this isn't the first time I've run into this issue: I want to install a
> > port using clang4.0 or GCC7 & then need to go through & rebuild specific
> > dependencies using the same compiler / c++ library. Seems like in 'port'
> > we could provide information as to whether the port uses c++, and if so
> > keep information as to which c++ library was used for linking (e.g.):
> > xcode libc++, xcode libstdc++, MacPorts libc++, MacPorts libstdc++.
> > Then, when someone does something "stupid" like what I try to do way too
> > often, port can tell them so & ask if they really want to go through
> > with this & then offer to rebuild the c++ dependencies using the desired
> > compiler. It seems like offering compiler variants, while useful for
> > testing, isn't the most practical except on specific ports (e.g.: atlas,
> > scipy, numpy, openblas, octave, arpack, itsol, qrupdate). GR requires
> > just 5 dependent ports to be rebuilt (boost, cppunit, log4cpp, scipy,
> > uhd).
> >
> > This also got me wondering why libc++ is required for macOS 10.12, or
> > maybe that I'm missing something in the way libstdc++ (via libgcc-devel)
> > is built or used? If I can successfully install and use libstdc++ as the
> > primary linked-to c++ library, then is it a legit way to install
> > c++-based projects? is this maybe just libgcc-devel, not libgcc? Am I
> > just missing something?
> 
> The problem is that all dependencies with C++ API need to be built
> against the same stdlib (which is something you figured out already).
> 
> And running the default compiler outside of MacPorts will link against
> libc++. And a number of software would not even compile with gcc (when
> using some Apple frameworks etc.).
> 
> Supporting one default variant is challenging enough. Supporting
> multiple configurations (Apple's stdlibc++ 2, libc++, gcc's libstdc++
> 3, gcc's libstdc++ 3 that's not using C++11 to make it possible to
> link against stdlibc++, ...) and then all the zillion workarounds to
> make dependencies somehow work is basically a mission impossible, so
> MP is trying to at least somewhat take care of one reasonable default
> (potentially two by partially supporting libc++ on older systems).
> 
> Linking against gcc's libstdc++ is not an option for default
> configuration.
> 
> But I totally agree that it would be nice if:
> - MacPorts would store the compiler and stdlib being used for each
> individual binary archive
> - it was possible to force recompilation of dependencies with another
> compiler/stdlib (and then switch back to the default one)
> - it was slightly easier to switch the system compiler/stdlib (in
> particur switching to the latest gcc on 10.5 for example)
> - we had official support for libc++ on older systems (including
> binary archives)
> 
> That requires some work though and I don't see it really likely that
> someone would go and implement all of that. We were not even able to
> carry out the last point yet.

c++ library usage

[Michael Dickens]

Hi MP devs - A hopefully brief discussion of / query about c++ library
usage, with a little background. What I describe below works for me,
which makes me wonder if what I'm doing is nonstandard use of 'port' or
what's going on ...

GNU Radio devs were asked whether GR compiles using GCC7 cleanly, so I
decided to give it a try on my macOS setup (10.12 most recent of
everything running on a MacBook Pro Retina Touchpad; standard MacPorts
install from GIT). Installing GCC7 was pretty simple, but of course GR
didn't link because some of its dependencies were not built using
libstdc++ from libgcc-devel, so the C++ library wasn't correct & mixing
C++ libraries doesn't generally work anyway.

Adding some temporary code to the Portfiles of those dependencies
allowed me to install them with compiler variants, which did the trick &
GR built cleanly & even passes "make test". The dependencies also work,
even though they are linked to libgcc-devel's libstdc++; they do not use
libc++ -- directly or indirectly from the look of it. Thus, I was able
to pretty quickly report back that GR is, or will be shortly when I get
some pull requests in place, compatible with GCC7. There are plenty of
deprecation warnings, but we can ignore those for now.

The above got me thinking about c++ library linking and usage, because
this isn't the first time I've run into this issue: I want to install a
port using clang4.0 or GCC7 & then need to go through & rebuild specific
dependencies using the same compiler / c++ library. Seems like in 'port'
we could provide information as to whether the port uses c++, and if so
keep information as to which c++ library was used for linking (e.g.):
xcode libc++, xcode libstdc++, MacPorts libc++, MacPorts libstdc++.
Then, when someone does something "stupid" like what I try to do way too
often, port can tell them so & ask if they really want to go through
with this & then offer to rebuild the c++ dependencies using the desired
compiler. It seems like offering compiler variants, while useful for
testing, isn't the most practical except on specific ports (e.g.: atlas,
scipy, numpy, openblas, octave, arpack, itsol, qrupdate). GR requires
just 5 dependent ports to be rebuilt (boost, cppunit, log4cpp, scipy,
uhd).

This also got me wondering why libc++ is required for macOS 10.12, or
maybe that I'm missing something in the way libstdc++ (via libgcc-devel)
is built or used? If I can successfully install and use libstdc++ as the
primary linked-to c++ library, then is it a legit way to install
c++-based projects? is this maybe just libgcc-devel, not libgcc? Am I
just missing something?

Thanks for your thoughts & opinions. - MLD

Re: [macports-ports] branch master updated: qt4-mac: Fix pointer comparison with 0.

[Michael Dickens]

What both of you write is probably technically correct. These are
patches from elsewhere and, in my reading, make sense based on context.

Rev-bump? Maybe; not clear if that's really necessary. We can always do
that, but since it's Qt4 I'm inclined to not do so unless someone
complains. These fixes were, after all, really just to get qt4-mac
compiling using macports-clang-4.0.

That said, I'll rev-bump if folks really think it's necessary. I just
hate doing so any more often than necessary for qt4-mac since it takes
so long to build. - MLD

Re: cppunit requires C++11 capable compiler now

[Michael Dickens]

The new CppUnit has an interesting issue: #include'ing the header,
whether directly or indirectly, results in requiring linking to the
library, because there is a new static variable in the primary namespace
in the header.

I think this is poor programming because, as an example, I might
#include a header that in turn #include's the log4cpp header, but might
project doesn't use or require log4cpp & this indirect inclusion forces
it to do so.

I think that the issue should be fixed upstream, but I'd like to suggest
to them a reasonable fix. Thus, I'm trying to understand why they want
to do it that way in the first place, what they are trying to do, before
creating a viable patch (the current patch in that port doesn't work in
all cases, but it fixes the immediate issue that I mention above).

The variable name is "appenderMapStorageInitializer" and it is located
in "include/log4cpp/Appender.hh". I value anyone's thoughts on what's
going on & the proper way to fix it.

Cheers! - MLD

Re: [GSoC] Call for Mentors GSoC 2017

[Michael Dickens]

I'm up for being a mentor again, for the correct student.

Do we have a MP GSoC website up yet? The best I can find is <
https://trac.macports.org/wiki/SummerOfCode >, which is for 2015.

Cheers! - MLD

On Mon, Feb 6, 2017, at 10:52 PM, Jackson Isaac wrote:
> Hello everyone,
> 
> As you all might be knowing GSoC season has started and they are
> accepting organization applications until February 9, 2017, 17:00
> (UTC).
> 
> I would like to invite you all and know who all would like to mentor
> some awesome students this year to get on-board with MacPorts.
> 
> I have already started the application process by coordinating with
> Rainer. If we have sufficient mentors and a admin and backup admin(s),
> we can move ahead with the application process.
> 
> Please feel free to reply to this thread if you are interested in
> participating as a mentor for GSoC 2017 with The MacPorts Project.
> 
> Call out for mentors and admin from GSoC 2015:
> Jeremy, Clemens,
> 
> Would you like to be the admin/backup admin again this year ?
> 
> Clemens, Lawrence, Michael, Rainer,
> 
> There are some of your ideas in the ideas list, would you like to
> mentor GSoC students this year ?
> 
> Bradley has volunteered to mentor this year.
> 
> -- 
> Jackson Isaac

Qt5 on 10.7?

[Michael Dickens]

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