Re: gcc, AVX (and newer) intrinsics and binutils

[Christopher Jones]

> Either way, benchmarks like these are rarely representative of real-world 
> performance in *[y]our* workloads. My own experience over the years has been 
> that GCC gives measurably better performance and that in cases where every 
> last 
> drop doesn't count you were better off using clang because it compiled so 
> much 
> faster. The differences have been disappearing but clang still doesn't win 
> across the board with a clear advance.
> 
> That's enough for me in itself as an argument to try to make GCC integrate 
> and 
> perform as well as possible on Mac, because some users might benefit. Hence 
> my 
> interest in support for the AVX (and newer) instruction sets.

Funny how the same data can lead to very different conclusions with different 
people. 

My reading is there is, on average across the board, there is no clear 
advantage/disadvantage to either gcc or clang, such that I am not really sure 
its warranted to expend a lot of effort to keep gcc alive on OSX, when upstream 
have clearly placed themselves 100% in the clang boat. That said, you are of 
course completely free to experiment yourself but I would say we should not 
accept any patches into MacPorts for this unless they a) do not require 
significant patching of the gcc builds that upstream does not accept and b) 
provides a rock solid gcc build that works in all cases without any nasty 
nuances (such as the library linkage changes you recently posted). If you can 
do both of these, great, but I admit I am quite dubious.

Chris

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

Re: How to keep uncommitted work in a git clone

[Christopher Jones]

Hi,

The other thing to realise with git is commits are a lot cheaper, as in the 
first instance they are only to your local checkout. So if you have a bunch of 
’this commit is just so I can save the current state of this branch and switch 
to another’ commits these can be squashed before you eventually push that 
branch upstream and submit a PR for it, so they never appear in the final 
history. For this reason committing partially completed pieces of work is not 
an issue, as you can finally squash them to a single ‘this implements this’ 
commit before pushing it.

cheers Chris

> On 5 Nov 2016, at 10:34 am, Christopher Jones <jon...@hep.phy.cam.ac.uk> 
> wrote:
> 
> 
> Hi,
> 
> I did the svn->git translation myself at work in the recent past and went 
> through exactly the same things as you are now. Git and Svn are very 
> different in some regards and workflows that worked with svn simply do not 
> with git. The ‘make all changes on master and commit only what I want each 
> time’ is one pattern from svn that does not map well to git. It took me a 
> while to realise it but branches are I am afraid really the best way forward 
> here. It does take a while to get use to but once you do it starts to make 
> more and more sense, and now I would not want to go back. 
> 
> Chris
> 
>> While I understand the benefit in principle of working on separate branches 
>> for separate tasks, this is not how I have been using my MacPorts Subversion 
>> working copy for the past 9 years. I keep most the my modifications I'm 
>> working on in that working copy. If I want to remind myself to include a 
>> change with the next version of curl, I make the change to the curl portfile 
>> and leave it there, so that when "port livecheck curl" next lets me know 
>> there's an update, the change will be there for me, ready to be included 
>> with the update commit.
>> 
>> Committing that curl work in progress to a separate branch implies that I 
>> will remember -- later, when livecheck tells me about a curl update -- that 
>> I had other work I wanted to include with that update, and which branch I 
>> had put it on.
>> 
>> Even today, I forgot to remove "# $Id$" lines from ports that I committed. 
>> It's not a big deal, but it had been my plan to do so. I would like to 
>> remove the Id lines from all my ports now, and not commit that change, so 
>> that the change is there ready to go when I do make the next commit to those 
>> ports.
>> 
>> 
>> ___
>> macports-dev mailing list
>> macports-dev@lists.macosforge.org <mailto:macports-dev@lists.macosforge.org>
>> https://lists.macosforge.org/mailman/listinfo/macports-dev 
>> <https://lists.macosforge.org/mailman/listinfo/macports-dev>

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

Re: How to keep uncommitted work in a git clone

[Christopher Jones]

Hi,

I did the svn->git translation myself at work in the recent past and went 
through exactly the same things as you are now. Git and Svn are very different 
in some regards and workflows that worked with svn simply do not with git. The 
‘make all changes on master and commit only what I want each time’ is one 
pattern from svn that does not map well to git. It took me a while to realise 
it but branches are I am afraid really the best way forward here. It does take 
a while to get use to but once you do it starts to make more and more sense, 
and now I would not want to go back. 

Chris

> While I understand the benefit in principle of working on separate branches 
> for separate tasks, this is not how I have been using my MacPorts Subversion 
> working copy for the past 9 years. I keep most the my modifications I'm 
> working on in that working copy. If I want to remind myself to include a 
> change with the next version of curl, I make the change to the curl portfile 
> and leave it there, so that when "port livecheck curl" next lets me know 
> there's an update, the change will be there for me, ready to be included with 
> the update commit.
> 
> Committing that curl work in progress to a separate branch implies that I 
> will remember -- later, when livecheck tells me about a curl update -- that I 
> had other work I wanted to include with that update, and which branch I had 
> put it on.
> 
> Even today, I forgot to remove "# $Id$" lines from ports that I committed. 
> It's not a big deal, but it had been my plan to do so. I would like to remove 
> the Id lines from all my ports now, and not commit that change, so that the 
> change is there ready to go when I do make the next commit to those ports.
> 
> 
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org 
> https://lists.macosforge.org/mailman/listinfo/macports-dev 
> 
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: New project members: jonesc

[Christopher Jones]

Thanks All !

> On 2 Nov 2016, at 7:07 pm, Lawrence Velázquez  wrote:
> 
>> On Nov 2, 2016, at 2:20 PM, Rainer Müller  wrote:
>> 
>> Please join us in welcoming the following new MacPorts project member:
>> 
>> - Chris Jones (jonesc)
>> 
>> We look forward to continued excellent contributions!
> 
> Yay!
> 
> vq
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev

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

Re: Issues with oudated ports / GitHub

[Christopher Jones]

> On 7 Oct 2016, at 8:12 pm, Ryan Schmidt  wrote:
> 
> 
>> On Oct 7, 2016, at 1:40 PM, Lawrence Velázquez  wrote:
>> 
>>> On Oct 7, 2016, at 2:09 PM, Chris Jones  wrote:
>>> 
>>> Currently, once they find out about svn, and trac
>> 
>> We will still use Trac for issue tracking, although I believe someone is
>> looking into integrating GitHub sign in.
> 
> Rainer and Clemens looked into this and got it up and running on our test 
> installation.
> 

So what exactly does this mean ?

Because, honestly, once the migration to GitHub is done unless comments sent to 
a github pull request are automatically sync’ed to trac, and vice versa, I do 
not see how trac can be maintained as a via system for discussing the pull 
requests (and frankly I din’t really see why you would want to).

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

Re: Issues with oudated ports / GitHub

[Christopher Jones]

> On 7 Oct 2016, at 8:08 pm, Lawrence Velázquez <lar...@macports.org> wrote:
> 
>> On Oct 7, 2016, at 2:58 PM, Christopher Jones <jon...@hep.phy.cam.ac.uk> 
>> wrote:
>> 
>>> On 7 Oct 2016, at 7:40 pm, Lawrence Velázquez <lar...@macports.org> wrote:
>>> 
>>>> On Oct 7, 2016, at 2:09 PM, Chris Jones <jon...@hep.phy.cam.ac.uk> wrote:
>>>> 
>>>> Currently, once they find out about svn, and trac
>>> 
>>> We will still use Trac for issue tracking, although I believe someone is
>>> looking into integrating GitHub sign in.
>> 
>> Personally I think we have to migrate away from trac as well. Pull
>> requests in GitHub will largely replace what happens in trac for
>> submission of patches and the discussion of them. If we stick with
>> trac for issues then for me it will be an utter mess.
> 
> We will not be migrating to GitHub Issues in its current form. Several
> of us (not me) have already evaluated it as a possible Trac replacement
> and concluded that it is insufficient for our needs.

OK… I predict a lot discussion will naturally start to happen associated with 
the pull requests, as that will be the most natural place to discuss them, so I 
think this decision will need to be re-assessed at some ...

Chris

> 
> vq

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

Re: Issues with oudated ports / GitHub

[Christopher Jones]

> On 7 Oct 2016, at 7:40 pm, Lawrence Velázquez  wrote:
> 
>> On Oct 7, 2016, at 2:09 PM, Chris Jones  wrote:
>> 
>> Currently, once they find out about svn, and trac
> 
> We will still use Trac for issue tracking, although I believe someone is
> looking into integrating GitHub sign in.

Personally I think we have to migrate away from trac as well. Pull requests in 
GitHub will largely replace what happens in trac for submission of patches and 
the discussion of them. If we stick with trac for issues then for me it will be 
an utter mess.

Chris


> 
> vq

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

Re: Issues with oudated ports / GitHub

[Christopher Jones]

> On 7 Oct 2016, at 7:38 pm, Daniel J. Luke  wrote:
> 
> On Oct 7, 2016, at 2:09 PM, Chris Jones  wrote:
>>> moving to GitHub doesn't magically make more interested parties make 
>>> quality contributions.
>> 
>> I agree that moving to github is not going to suddenly make people where not 
>> not previously looking for a packaging system for OSX suddenly start using 
>> macports. However, I completely agree with Marcel that moving to github will 
>> mean if someone does find their way to macports they will be more likely to 
>> stay and contribute, as the chances are they will already be familiar with 
>> git, as thats what the cool kids do these days. Currently, once they find 
>> out about svn, and trac, and yes i agree the little tired looking web pages, 
>> i suspect they are more likely to drift away. So the move to git will help.
> 
> the cool kids also aren't writing 'tcl' these days …

Indeed, but changing that is well beyond the scope of the current discussion. 
It shouldn’t ave a bearing on the migration to git.

> 
> -- 
> Daniel J. Luke
> 
> 
> 

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

Re: No Xcode 8 CLT for El Capitan

[Christopher Jones]

> 
> 
> A user just added a comment to the cmake issue that indicates that it is 
> actually an undeclared type in the Apple header file, and that a bug report 
> has now been filed with Apple.  It also includes a work around:  
> https://trac.macports.org/ticket/52258#comment:13 
> 

That bug report is referring to the header /usr/local/include/pthread.h …. 
Apple did not ship that file…

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

Re: llvm-3.9 "new libstdc++ ABI compatibility"

[Christopher Jones]

> On 2 Sep 2016, at 7:41 pm, René J.V. Bertin  wrote:
> 
> On Friday September 02 2016 13:45:56 Lawrence Velázquez wrote:
> 
>>> Or is it something that will in fact mostly/only benefit Linux users?
>> 
>> Yes. This is meant to keep Clang compatible with ABI changes to GCC 5.1's 
>> libstdc++.
> 
> That's about time ... GCC 6.1 is out …

you are behind the times. gcc 6.2 is the current pro version…

> 
>> P.S. Incidentally, this implies that g++ 4.x is also ABI-incompatible with 
>> libstdc++ 5.1. Have we encountered any issues along these lines?
> 
> Funny enough I haven't noticed any issues with that on Linux; at some point I 
> started using GCC 5 (and now GCC 6) without rebuilding my whole system, and 
> haven't run into any issues. Maybe that means that libstdc++ is linked in as 
> a private library and designed in such a way that different versions can be 
> loaded in memory? I do remember that clang itself cannot be built with GCC 5 
> (on Linux, clang 3.5 IIRC).

Fixing that is I think part of the update. Not being able to build clang with 
gcc > 4 was a major issue as it meant we could not have a stack of my 
experimental software built with gcc > 4, as ROOT internally builds LLVM (which 
actually is where the issue is) as part of the cling interpreter.

Chris

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

Re: How to discontinue ports completely (py26 deprecation) ...

[Christopher Jones]

> On 12 Aug 2016, at 11:30 pm, Fred Wright  wrote:
> 
> 
> On Fri, 12 Aug 2016, Chris Jones wrote:
>> On 11/08/16 20:40, Fred Wright wrote:
> [...]
>>> Well, leaving something alone that's working just fine is hardly much of a
>>> maintenance burden.
>> 
>> On the other hand, whats the rationale for keeping 2.6, given 2.7 is the
>> official upstream production version of the 2.x series. What use case
>> requires 2.6 and cannot move to 2.7 ?
> 
> Testing code against 2.6 (among others), because it's intended to run on a
> wide range of platforms, and one wants to make as few assumptions as
> possible about what Python version(s) the end user might have installed.
> Some distros lag *way* behind in versions of various things, including
> Python.
> 
> If the python.org folks had their way, all 2.x versions would be
> eradicated, but there were too many pitchforks at the gates to let that
> happen. :-)

I agree there is no way to migrate completely to 3.x, but I am still not really 
convinced keeping both the 2.6 and 2.7 versions in MacPorts is worth the 
effort. 2.6 needs to be dropped sometime...

Chris

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



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

Re: variants

[Christopher Jones]

> On 12 Apr 2016, at 8:50 pm, Daniel J. Luke <dl...@geeklair.net> wrote:
> 
> On Apr 12, 2016, at 3:04 PM, Christopher Jones <jon...@hep.phy.cam.ac.uk> 
> wrote:
>>> How do other package managers (that don't have variants) deal with ROOT6?
>> 
>> I guess they have to decide a set of options that most people want, and just 
>> go with that.
> 
> and we can't do that?
> 
>>> How do users know what functionality they have installed when they install 
>>> ROOT6 from source?
>> 
>> If they are installing from source they are expected to know what they are 
>> doing, and therefore pick the options they need. They are reasonably well 
>> documented.
> 
> ok, so it's just actively user-hostile

thats a matter of opinion.

 As far as ROOT is concerned if a user wants a custom option, they are expected 
to know why, and what that entails. I do not view that as user hostile, just 
expecting the user to have some idea as to what they want and what that means. 
If they don’ t wh=ant to do that by hand use macports variants (see below).

> 
>>> How do users add additional functionality that wasn't built when they first 
>>> built ROOT6? [the answer is probably 'rebuild’]
>> 
>> you can’t. Reinstall with the new options.
> 
> and again user-hostile

I disagree.

> 
>> None of the above changes my opinion on what Macports should do.
> 
> the current situation is basically the same as what upstream provides when 
> building from source.

No, it is very different.

reinstalling with a new set of variants is a lot easier than figuring but by 
hand what options need to be specified to achieve that, and what other 
dependencies are required. MP, handles all that just fine.

Reinstalling with new variants is, as far as I am concerned, not a major issue.

> 
> Am I missing somthing? Changing how default variants works only fixes one 
> case:
> new install, installing something that depends on a variant of some other port
> 
> It breaks existing behavior:
> port install A (which installs B as a dependent) is currently the same as 
> port install B && port install A
> 
> It doesn't fix things when the dependent is already installed.
> 
> This could be fixed by adding variants to the dependency engine OR by making 
> use of the existing dependency engine (ie, breaking the port up into pieces 
> so that things can depend on what they actually need) OR by just getting rid 
> of variants (batteries-included install).

Variants aint going away any time soon, as far as I am concerned.


Chris


> 
> -- 
> Daniel J. Luke
> 
> 
> 



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

Re: variants

[Christopher Jones]

Hi,

> On 12 Apr 2016, at 7:56 pm, Daniel J. Luke <dl...@geeklair.net> wrote:
> 
> On Apr 12, 2016, at 2:52 PM, Christopher Jones <jon...@hep.phy.cam.ac.uk> 
> wrote:
>>>> Some of them create additional libraries for the new features, some just 
>>>> add the functionality to existing ones. Most will also extend the 
>>>> introspection system as part of root. None can be built as afterthoughts. 
>>>> You have to configure ROOT from the start with the features you want. So 
>>>> for this port there is no chance in hell I am going to implement them as 
>>>> sub-ports. 
>>> 
>>> It would be nice if upstream could be convinced to 'fix' this.
>> 
>> You’ll need to convince them (and me) first its a bug that needs fixing. I 
>> don’t see it that way.
> 
> How do other package managers (that don't have variants) deal with ROOT6?

I guess they have to decide a set of options that most people want, and just go 
with that.

> 
> How do users know what functionality they have installed when they install 
> ROOT6 from source?

If they are installing from source they are expected to know what they are 
doing, and therefore pick the options they need. They are reasonably well 
documented.

> 
> How do users add additional functionality that wasn't built when they first 
> built ROOT6? [the answer is probably 'rebuild’]

you can’t. Reinstall with the new options.

None of the above changes my opinion on what Macports should do.

Chris

> 
> -- 
> Daniel J. Luke
> 
> 
> 



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

Re: variants

[Christopher Jones]

> On 12 Apr 2016, at 7:49 pm, Daniel J. Luke <dl...@geeklair.net> wrote:
> 
> On Apr 12, 2016, at 1:34 PM, Christopher Jones <jon...@hep.phy.cam.ac.uk> 
> wrote:
>> Take if you want, as a real world case, ROOT6, which I know well. It has a 
>> large number of variants, because upstream’s build system offers all these 
>> as optional extras. Many of them have dependencies I do not wish to force on 
>> all users, if they don’t require that feature. 
>> 
>> Some of them create additional libraries for the new features, some just add 
>> the functionality to existing ones. Most will also extend the introspection 
>> system as part of root. None can be built as afterthoughts. You have to 
>> configure ROOT from the start with the features you want. So for this port 
>> there is no chance in hell I am going to implement them as sub-ports. 
> 
> It would be nice if upstream could be convinced to 'fix' this.

You’ll need to convince them (and me) first its a bug that needs fixing. I 
don’t see it that way.

Chris




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

Re: variants

[Christopher Jones]

> On 12 Apr 2016, at 4:59 pm, Daniel J. Luke  wrote:
> 
> On Apr 12, 2016, at 11:49 AM, Chris Jones  wrote:
>> A lot of projects simply aren't built in a way that would allow that. The 
>> whole package (library, whatever) needs to be configured once with all the 
>> options, and built once. sub ports for the additional features simply aren't 
>> a option in main (most, I would bet) cases.
> 
> Do they build the same output with different features?
> 
> Port A with and without +foo builds lib-A.dylib
> 
> And not, Port A without +foo builds lib-A.dylib and with +foo builds 
> lib-A.dylib & lib-A-foo.dylib?

Both, and all points in-between. I wasn’t really thinking of specific cases, 
just in generality. 

Take if you want, as a real world case, ROOT6, which I know well. It has a 
large number of variants, because upstream’s build system offers all these as 
optional extras. Many of them have dependencies I do not wish to force on all 
users, if they don’t require that feature. 

Some of them create additional libraries for the new features, some just add 
the functionality to existing ones. Most will also extend the introspection 
system as part of root. None can be built as afterthoughts. You have to 
configure ROOT from the start with the features you want. So for this port 
there is no chance in hell I am going to implement them as sub-ports. 

> 
> IIRC the subversion-bindings ports didn't initially have nice 'install' 
> targets, so we manually cleaned up post-destroot so that they would just have 
> the additional libs that were necessary. The actual 'build' ends up 
> duplicating some build products that don't get installed for the bindings 
> ports (because they're already installed by the main port) - but it's worth 
> it to have everything "just work" for our end-users.

That sounds just like the hackery needed in the portfiles to implement this 
that I think we should avoid. For me, if upstream implements their build system 
with such an idea of additional ‘plugins’, that maps cleanly to sub-ports, then 
great. If not I am not of the opinion we should be trying to force things to 
work in ways upstream didn’t envisage.

Chris

> 
> -- 
> Daniel J. Luke
> 
> 
> 



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

Re: PortGroup directory hierarchy/priority

[Christopher Jones]

> On 2 Apr 2016, at 7:48 pm, René J.V. Bertin  wrote:
> 
> On Saturday April 02 2016 19:27:38 Rainer Müller wrote:
> 
>> This is not in any way slower than rsync. With no actual changes, a
> 
> Maybe not if you do it very regularly. That quickly changes once you start 
> increasing the intervals, in my experience.


Not in my experience. I use an svn checkout as my main sources and do not 
update too regularly, but when I do its pretty fast.

Chris

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

Re: New Mac OS Forge administrator

[Christopher Jones]

> On 20 Nov 2015, at 8:15 p.m., Bradley Giesbrecht  wrote:
> 
>> On Nov 19, 2015, at 6:49 PM, Ryan Schmidt  wrote:
>> 
>> Dear MacPorts users and developers,
>> 
>> I'm pleased finally to be able to tell you that I have been hired to be your 
>> new Mac OS Forge administrator. I have been involved in improving MacPorts 
>> for years as a committer and as a manager, and now as a Mac OS Forge 
>> administrator I will work on ensuring our infrastructure runs smoothly too.
>> 
>> I apologize for the downtime we've experienced in the past months. My 
>> priority right now is to resolve the existing issues, as I become familiar 
>> with the systems.
>> 
>> Please continue to report new problems with MacPorts infrastructure (server 
>> not working) as you have before, using the server/hosting component in Trac 
>> or via email to admin at macosforge dot org. And continue to report MacPorts 
>> administrative issues (mailing list issues, commit access requests) to 
>> portmgr at macports dot org.
>> 
>> Thanks for your patience and support and thank you for using MacPorts.
>> 
>> -Ryan
> 
> Bam, confidence restored!
> 
> Congratulations.

Absolutely. Was concerned where things where heading. not any more…

Chris



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

Re: Showing the full ./configure command also with -v, not just with -d

[Christopher Jones]

> On 30 Oct 2015, at 16:41, Sean Farley  wrote:
> 
> 
> Mojca Miklavec > writes:
> 
>> Hi,
>> 
>> I would really appreciate it if I could see the complete configure
>> command already in verbose mode (port -v configure), not just debug
>> mode (port -d configure). The same applies to build/make, but usually
>> that one doesn't contain so much extra parameters.
>> 
>> The command "port -d ..." is wy too verbose, hardly useful for any
>> port maintainer, and it's sometimes very difficult to find the
>> relevant output, while "port -v ..." seems just perfect for showing
>> that. We already get hundreds of lines of output during "./configure",
>> so one extra line would bring a lot of benefit with hardly any
>> penalty.
>> 
>> (Environmental variables would also be very helpful, even though I
>> wouldn't know whether they make more sense in verbose or debug mode. I
>> would like to see them in verbose mode as well, but it's still ok if
>> they are more hidden than the configure command itself.)
> 
> I have wanted this for a very long time!

same here. But please, if enabled, do so for all build systems (for instance 
cmake).

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


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

Re: libexec vs lib

[Christopher Jones]

Your question suggests you don’t really understand what lib and libexec are 
for. They serve rather different purposes. There are plenty of resources on the 
web explaining the difference.

> On 19 Sep 2015, at 5:16pm, Andrew L. Moore  wrote:
> 
> Guys,
> Macports appears to install qt5-mac, llvm-3.5 and llvm-3.7 wholesale under 
> libexec.  This is not a traditional destination. Is there a reason for 
> choosing libexec over lib?
> 
> 
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev

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

Re: Changing port group default options

[Christopher Jones]

Hi,

 In my opinion increasing the version of the portgroup should be
 reserved for (fundamentally) incompatible changes or when the syntax
 changes. (For example when switching from qt4 to qt5 if the portgroup
 would initially be just qt. Or if the python PortGroup would start
 working for software written in C++ with Python bindings.) I agree
 that this kind of change in the cmake PortGroup is almost the
 bordercase, but I feel that starting a new revision would introduce
 way more work than benefits.

Incompatible changes would warrant an increase to the *major* portgroup 
version, so from 1.0 to 2.0 say. Increasing it from 1.0 to 1.1 seems to me 
pretty suited to this case, and thus I agree would have been a good idea.

Chris

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

Re: Current best practice to select GCC compiler in Portfile

[Christopher Jones]

The best practise is not to do it, unless it is for non C++ code (C, fortran, 
..), as using gcc for C++ will lead to C++ runtime issues if the binaries you 
produce are used with others that where produced using clang, which like it or 
not is now the default OS X compiler.

 On 26 Feb 2015, at 1:56pm, Artur Szostak aszos...@partner.eso.org wrote:
 
 Hi,
 
 I couldnt really find this information and I see lots of different approaches 
 in the Portfiles.
 What is the current best practice to select the GCC compiler over the XCode 
 clang one used by default?
 I dont care much about the exact version of the GCC compiler used, but it 
 must be gcc rather than clang.
 
 Kind regards.
 
 Artur
 ___
 macports-dev mailing list
 macports-dev@lists.macosforge.org
 https://lists.macosforge.org/mailman/listinfo/macports-dev



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

Re: OCE X11/XQuartz dependency

[Christopher Jones]

On 23 Jun 2014, at 1:04am, Mark Brethen mark.bret...@gmail.com wrote:

 OCE depends on X11/XQuartz. What commands are needed to check if it has been 
 installed?

Don’t. The OCE port should not use (by which I mean link against) any third 
party X11 libraries, but instead declare a dependency against the MacPorts ones 
(port:xorg-libX11) and make sure the port builds/links against these, as 
opposed to any others from Xquartz or otherwise. Note this is a separate issue 
as to what X11 version the user decides to use as their server, they are free 
to use whatever they want. This has no bearing on the libraries OCE should link 
against, which for consistency should always be the MP ones.

Chris



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

Update ticket - xrootd

[Christopher Jones]

Hi,

Could someone please take a look at and commit

https://trac.macports.org/ticket/43743

thanks in advance

Chris

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

Re: Update ticket - xrootd

[Christopher Jones]

Mucho gracias …

On 20 May 2014, at 4:04pm, Frank Schima m...@macports.org wrote:

 Hi Chris,
 
 
 Done in r120250 [1]. 
 
 
 Cheers!
 Frank
 
 [1] https://trac.macports.org/changeset/120250
 
 On May 20, 2014, at 1:14 AM, Christopher Jones jon...@hep.phy.cam.ac.uk 
 wrote:
 
 Hi,
 
 Could someone please take a look at and commit
 
 https://trac.macports.org/ticket/43743
 
 thanks in advance
 
 Chris___
 macports-dev mailing list
 macports-dev@lists.macosforge.org
 https://lists.macosforge.org/mailman/listinfo/macports-dev
 
 ___
 macports-dev mailing list
 macports-dev@lists.macosforge.org
 https://lists.macosforge.org/mailman/listinfo/macports-dev



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

Buildbot failure for new ROOT ports

[Christopher Jones]

Hi,

Could someone explain the reason for the failure in step 8 of

https://build.macports.org/builders/buildports-mavericks-x86_64/builds/3369

The only thing I can see indicating a problem is

 in dir /var/buildbot/ports-slave/buildports-mavericks-x86_64/build (timeout 
1200 secs)

What is step8 ? And whats timing out above ?

cheers Chris

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

Re: Building clang/cling 3.5 for ROOT on Lion

[Christopher Jones]

Hi,

For me, I’m afraid, I think this means ROOT6 can only be properly supported on 
10.8 or newer. As its only these OS versions that have c++11 support. If 
upstream have decided ROOT from version 6 onwards requires c++11 support, I am 
not going to second guess them.

I previously had variants in the ROOT port that allowed users to build the C++ 
sources with gcc, but this lead to all the well know issues and was removed. I 
will not be adding it back.

Unofficially, you might have luck on 10.7 with

 sudo port install root6 configure.compiler=macports-gcc-4.8

but given the issues, it will have to stay unofficial...

Chris

On 7 Apr 2014, at 11:13pm, Mojca Miklavec mo...@macports.org wrote:

 Hi,
 
 I would like to ask for advice about how to properly support building
 ROOT 6 (which builds clang/cling 3.5 as part of the installation) on
 Lion.
 
 I'm aware of http://trac.macports.org/wiki/FAQ#libcpp. But it's not
 clear to me if dependency on clang 3.5 means that one will be unable
 to to run ROOT 6 on 10.7 and earlier. Or if we just need to blacklist
 certain compilers.
 
 The first response from upstream was:
 
 ROOT6 requires C++11, which is supported (using libc++) on 10.8
 and 10.9 e.g. with XCode 5.1.
 
 For 10.7 you can get GCC 4.7 or 4.8 from the usual Mac packagers,
 or build clang with libc++ yourself; either one should work but the
 former might be simpler.
 
 Mojca
 ___
 macports-dev mailing list
 macports-dev@lists.macosforge.org
 https://lists.macosforge.org/mailman/listinfo/macports-dev



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

Re: Building clang/cling 3.5 for ROOT on Lion

[Christopher Jones]

p.s. whats the most recent MacPorts clang compiler you can install on OSX10.7 ?

On 8 Apr 2014, at 12:03am, Christopher Jones jon...@hep.phy.cam.ac.uk wrote:

 Hi,
 
 For me, I’m afraid, I think this means ROOT6 can only be properly supported 
 on 10.8 or newer. As its only these OS versions that have c++11 support. If 
 upstream have decided ROOT from version 6 onwards requires c++11 support, I 
 am not going to second guess them.
 
 I previously had variants in the ROOT port that allowed users to build the 
 C++ sources with gcc, but this lead to all the well know issues and was 
 removed. I will not be adding it back.
 
 Unofficially, you might have luck on 10.7 with
 
 sudo port install root6 configure.compiler=macports-gcc-4.8
 
 but given the issues, it will have to stay unofficial...
 
 Chris
 
 On 7 Apr 2014, at 11:13pm, Mojca Miklavec mo...@macports.org wrote:
 
 Hi,
 
 I would like to ask for advice about how to properly support building
 ROOT 6 (which builds clang/cling 3.5 as part of the installation) on
 Lion.
 
 I'm aware of http://trac.macports.org/wiki/FAQ#libcpp. But it's not
 clear to me if dependency on clang 3.5 means that one will be unable
 to to run ROOT 6 on 10.7 and earlier. Or if we just need to blacklist
 certain compilers.
 
 The first response from upstream was:
 
 ROOT6 requires C++11, which is supported (using libc++) on 10.8
 and 10.9 e.g. with XCode 5.1.
 
 For 10.7 you can get GCC 4.7 or 4.8 from the usual Mac packagers,
 or build clang with libc++ yourself; either one should work but the
 former might be simpler.
 
 Mojca
 ___
 macports-dev mailing list
 macports-dev@lists.macosforge.org
 https://lists.macosforge.org/mailman/listinfo/macports-dev
 
 ___
 macports-dev mailing list
 macports-dev@lists.macosforge.org
 https://lists.macosforge.org/mailman/listinfo/macports-dev



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

Re: [116514] trunk/base/src

[Christopher Jones]

 
 of course, you are right, it should be changed to
 
 -if {$macosx_version == 10.5} {
 +if {$macosx_version eq 10.5} {
 
 Nonetheless: http://trac.macports.org/changeset/116781.

Th change to trunk/base/src/port1.0/portstartupitem.tcl looks suspicious - '!=' 
has been replaced with ‘eq’ ..

Chris



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

Re: C++11 on Mountain Lion and lower?

[Christopher Jones]

Hi,

 To follow up: the ML buildbot just succeeded building rethinkdb using
 FSF GCC 4.8 (obviously using MacPorts libstdc++). I guess the binaries
 will now use both
  - /opt/local/lib/libstdc++.dylib and
  - /usr/lib/libstdc++.dylib,
 but I suppose that will cause a lot less problems than mixing libc++ and
 libstdc++. Obviously this solution should only be used for ports that do
 *not* export a C++ API.

Is this really a good idea though. My recollection is, whilst not as bad as 
mixing libc++ and libstdc++ runtimes, mixing the two different libstd++ 
runtimes can still lead to problems…. ?

Chris



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

Re: C++11 on Mountain Lion and lower?

[Christopher Jones]

Hi,

 Under the constraints we have I think its the best solution possible.
 Alternatives would be
 
 - Mark the port as broken on systems  darwin13 :(
 - Build a private copy of all dependencies of rethinkdb against
   macports libstdc++. Since that includes boost and a couple of other
   rather large ports, I don't think this is a feasible solution either.
 - Get Apple to ship a version of libstdc++ that supports C++11 on
   outdated OS releases
 - Get Apple to make libc++ the default stdlib on all releases that have
   libc++
 
 None of those sound very appealing to me.

For that last one, it is not necessary to have Apple make that decision. 
macPorts could decide to release the current trunk, and force the use of libc++ 
on systems older than OSX10.9. This of course would force all users to 
recompile all their ports, and probably is not a solution for all OSX releases, 
as I guess the older ones probably don’t have any runtime supporting c++11….

To be honest, if it isn’t possible to do it properly, I would go with the top 
one above. At least it doesn’t pretend all is OK, when it isn’t. If upstream 
for a given port decides they are going to use c++11 features, unconditionally, 
they effectively they are making that decision for us.

Chris

 
 -- 
 Clemens Lang
 



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

Re: C++11 on Mountain Lion and lower?

[Christopher Jones]

Hi,

On 3 Dec 2013, at 8:13pm, Clemens Lang c...@macports.org wrote:

 On Tue, Dec 03, 2013 at 07:48:48PM +, Christopher Jones wrote:
 For that last one, it is not necessary to have Apple make that
 decision. macPorts could decide to release the current trunk, and
 force the use of libc++ on systems older than OSX10.9. This of course
 would force all users to recompile all their ports, and probably is
 not a solution for all OSX releases, as I guess the older ones
 probably don’t have any runtime supporting c++11….
 
 That would still require users that want to build their own C++ software
 to only use C++ APIs from libraries compiled by MacPorts. Strictly no
 linking against any C++ APIs provided by the OS in /usr/lib/*.dylib.
 
 I'm not sure that's what we currently want.

Nope, nor do I. Just mentioning it…

 
 To be honest, if it isn’t possible to do it properly, I would go with
 the top one above. At least it doesn’t pretend all is OK, when it
 isn’t. If upstream for a given port decides they are going to use
 c++11 features, unconditionally, they effectively they are making that
 decision for us.
 
 I'd do that if only systems below Lion were affected, but this would
 mean the port doesn't work on Mountain Lion and Mavericks has just been
 released, so I guess the majority of our user base still is on ML.

Oh, I agree it sucks. But still I feel this is kinda upstreams decision to 
make. Is this issue due to a new change in an upstream version ? Have we got in 
contact with the upstream devs to find out what their intentions are, and if 
they know this effectively rules out all OSX versions before 10.9 ? If they 
still insist, I am not sure we should second guess them...

 
 I think the FSF GCC solution involving libstdc++ from MacPorts is good
 enough for now, even if it is a hack. Reading the documentation on ABI
 compatibility for libstdc++ mentions all releases since GCC 4.3 use
 libstdc++.6.so (on Linux) as SONAME and should be compatible. The docs
 also explicitly mention they libstdc++ libraries are forward-compatible,
 so in theory one should always be able to substitute a libstdc++ library
 with a newer version. Of course, I'm not sure whether this also holds
 for multiple libstdc++ versions in the same address space.

Well yes, you can drop in a newer libstdc++ as a replacement for an older one, 
and applications linked against the old one should still work. The issue is 
that last point, about an application loading *both* runtimes at the same time. 
That I think can cause issues and should be avoided. I guess you can check with 
otool -L to see if this is happening with your hack ?

Chris
 
 -- 
 Clemens Lang
 



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

Re: C++11 on Mountain Lion and lower?

[Christopher Jones]

Hi,

On 3 Dec 2013, at 9:55pm, Ryan Schmidt ryandes...@macports.org wrote:

 
 On Dec 3, 2013, at 13:48, Christopher Jones wrote:
 
 For that last one, it is not necessary to have Apple make that decision. 
 macPorts could decide to release the current trunk, and force the use of 
 libc++ on systems older than OSX10.9. This of course would force all users 
 to recompile all their ports, and probably is not a solution for all OSX 
 releases, as I guess the older ones probably don’t have any runtime 
 supporting c++11….
 
 First we would need to write more code in base that could identify when ports 
 are installed with a different C++ runtime than that selected in 
 macports.conf, and rebuild those ports. Users will not know they need to 
 rebuild ports after such a change (since no previous MacPorts release has 
 made them do this, when not upgrading the OS), and if they don’t rebuild 
 ports things will break.
 
 I don’t think we record in the registry what C++ runtime was used to build a 
 port. So we might have to scan all installed files to see what C++ runtime 
 they link with.

I agree, its a royal pain all round. 

I think now is the right time for MacPorts to decide how its going to deal with 
this. I guess the number of packages that require c++11 is currently small, but 
I think this will slowly start to change. c++11 has a number of really neat 
features, so I am sure upstream devs. are going to want to start to use them, 
over time. I certainly do in the projects I work on...

Part of the problem, for me, is MacPorts insists on all OSX versions using the 
same set of port versions. There is no way, I think, of having different 
versions on different OSX releases. Note this is quite different to say the 
Linux world, where for instance the various Ubuntu/Fedora/Whatever 
distributions allow packages to update at different rates in each of their 
releases. If we had this possibility in MacPorts (putting assign the headache 
it would give maintainers) it would allow us deal with situations like this.

Assuming though the above is not to going to change anytime soon, the question 
is how to deal with this c++11 issue. The options are either a) Find a way to 
allow old OSX versions to use c++11, b) don’t update any port that starts to 
use c++11, as long as we ‘officially’ (whatever that means these days) support 
OSX releases without c++11 c) declare such ports as ‘broken’ on the older OSX 
releases.

For me, compiling with MacPorts gcc versions is not a solution along the lines 
of a) as it potentially mixes different libstdc++ runtimes, which is dangerous. 
Maybe the solution above, to force the use of libc++ on older systems (with 
some automatic rebuild) is a solution, but most probably it will not work on 
all systems, as some OSX release will not have any C++ runtimes that support 
c++11. Solutions b) and c) are not ideal at all.

Chris



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

Re: C++11 on Mountain Lion and lower?

[Christopher Jones]

Hi,

On 3 Dec 2013, at 11:43pm, Ryan Schmidt ryandes...@macports.org wrote:

 
 On Dec 3, 2013, at 16:23, Christopher Jones wrote:
 
 Part of the problem, for me, is MacPorts insists on all OSX versions using 
 the same set of port versions. There is no way, I think, of having different 
 versions on different OSX releases. Note this is quite different to say the 
 Linux world, where for instance the various Ubuntu/Fedora/Whatever 
 distributions allow packages to update at different rates in each of their 
 releases. If we had this possibility in MacPorts (putting assign the 
 headache it would give maintainers) it would allow us deal with situations 
 like this.
 
 Portfiles are Tcl scripts. The can do most anything. Whether they should is 
 another matter.

Didn’t realise it was technically possible. useful to know, thanks.
 
 Usually when different versions are available and needed for whatever reason 
 (including support for specific OS versions), we make separate ports. See 
 vineserver which is for 10.6 and newer and vineserver3 which is for 10.6 and 
 older, or graphviz-gui which is for 10.5 and newer and graphviz-oldgui which 
 works on any OS X version.

The problem then of course is you force ports that depend on these different 
versions, to know about these different versions, and to have some way of 
deciding which to pick.

 
 Some ports do vary their version based on the OS X version. See cctools and 
 ld64.
 

This is more what I was thinking for this case. Have the port use a newer c++11 
enabled version on OSX versions that support it, and a older version where they 
don’t.

Chris

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

Re: 10.9 and compiler

[Christopher Jones]

 
 
 Can we not use blacklists on 10.9?  Do we need to always use clang?  Or is 
 that only for C++ code that we have to use clang?
 
 On 10.9, clang is the only system compiler. So for OSX 10.9, you need to use 
 clang, for C C++, Obj-C etc.
 
 Thanks.  Technically, one could use gcc for C code, since it doesn’t link 
 against any C++ runtime???

the system ‘gcc’ on OSX 10.9 is actually clang…

MacBookPro ~  /usr/bin/gcc -v
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr 
--with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix

clang is the *only* system compiler. You could install one of macports gcc 
ports, and use that, but really its a much better option to get upstream to 
probably support clang...

Chris

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