Re: How to keep uncommitted work in a git clone

[Chris Jones]

On 04/11/16 05:39, David Bariod wrote:

Hello,

Personnally, I would just commit such change. It is cheap, can be
reworked later and be ketp safe in a private remote repository in case
of disaster.
With git there are no reason to not commit event not ready yet change set.


I would not do this, as you then might end up with a lot of intermediary 
commits in the history. better I think to work on independent projects 
on independent branches.


Chris



Best regards,
David

On Fri, Nov 4, 2016 at 2:56 AM, Ryan Schmidt > wrote:

With Subversion, I was accustomed to keeping changes in my working
copy that I was not ready to commit yet.

Git doesn't let me do that. It complains and tells me to git stash
and later git stash pop.

Well, I tried that. I git stashed, then made changes to curl and
committed them, and later when I tried to git stash pop, my other
changes that I had in my git clone were not restored. I have no idea
where they are now.

I can get these particular changes back from my old Subversion
working copy, but I don't understand how I'm meant to work with git
when I have changes that I'm not ready to commit yet, yet there are
other changes I need to make and commit elsewhere within that same
clone.

___
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


___
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

[Chris Jones]

On 04/11/16 04:18, Sterling Smith wrote:


On Nov 3, 2016, at 7:54PM, Arno Hautala  wrote:


On Thu, Nov 3, 2016 at 9:56 PM, Ryan Schmidt  wrote:


Well, I tried that. I git stashed, then made changes to curl and committed 
them, and later when I tried to git stash pop, my other changes that I had in 
my git clone were not restored. I have no idea where they are now.


There's also another paradigm to adopt which avoids stashing entirely.
Just always work in a branch and feel free to commit even if you're in
the middle of something. In your case, you're working on something
(let's say it's wget), but curl needs to be fixed too. Commit your
incomplete changes on the "wget-update" branch, `git checkout -b
curl-update master` to create and checkout a curl branch, complete
your work there, and then switch back to the "wget-update" branch.

This is my preference.  I tried stash as well once, and had trouble with it.


I would agree.

You should get out of the habit of working on the master branch. Leave 
that pristine and in sync with GitHub. For each separate project you are 
working out create a branch (from the master) and work on that. When you 
are ready you can then push that branch to GitHub and create a pull 
request for it.


Chris



-Sterling
___
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: git fetch fails because of gnutls_handshake

[Chris Jones]

On 29 Oct 2016, at 4:27 pm, Lawrence Velázquez  wrote:

>> On Oct 29, 2016, at 11:17 AM, René J.V. Bertin  wrote:
>> 
>> Does trac no longer auto-subscribe new participants? 
> 
> Our Trac has never automatically subscribed anyone except ticket
> reporters. Owners and Cc need to be set explicitly. I don't know if
> other projects do things differently.

I have fallen foul of this a few times, as pretty much all other issue tracking 
systems i have used indeed automatically adds anyone who sends a reply, to 
receive any future comments. Trac is a bit odd i would say in this regard to 
not do this.

But its true trac has never done this, so its not a recent change.

Chris
 
> 
> 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: port:qt5 and (proposed) port:qt5-kde cohabitation

[Chris Jones]

On 23 Oct 2016, at 3:14 am, Lawrence Velázquez  wrote:

>> On Oct 22, 2016, at 8:08 PM, Marko Käning  wrote:
>> 
>> in the light of the upcoming commit of the new 'qt5-kde' port I want
>> to ask (again) whether it would be acceptable, that we - for the sake
>> of housekeeping - store all KF5-related ports in a dedicated folder at
>> 
>>   dports/kf5
>> 
>> or whether it is really necessary, that all these KDE ports have to
>> live under
>> 
>>   dports/kde
>> 
>> just like all those port files belonging to KDE 3 and 4?
> 
> Why should KF5 get its own category? It's not special.
> 
>> - and both port collections having independent maintainers (Nicolas
>> and René)
> 
> This has no bearing on anything.
> 
>> it would make maintenance easier if one kept also their storage
>> locations separate, no?
> 
> I don't see why separating them would make anything easier. It's not as
> if there's any namespacing going on. The ports would still have to have
> unique names.
> 
>> Are there other reasons of not going for such an approach which we up
>> to now aren’t aware of, perhaps?
> 
> I think having top-level directories based on implementation details
> like language or framework are silly and pointless from a users'
> perspective, and we should not add anymore of them.
> 
> (No, I don't like the top-level "java", "php", "python", etc.
> directories, either.)

So... you are saying you would take these collections, and instead of grouping 
them together scatter them around in the other directories, like 'science' 
etc., depending on what sort of functionality they provide ? I think that would 
be much worse, sorry.

I also question would these directories are really for, users or developers ? I 
don't think users really get much exposure to them, they don't really have much 
bearing on how users find and install ports. For me, its more for the 
developers, so we should be flexible in how they are grouped depending on what 
makes sense to whoever is maintaining them. Grouping all the kde ports in one 
directory because they obviously share many details just makes sense to me. 

Chris

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

[Chris Jones]

> On 8 Oct 2016, at 11:29 am, Ryan Schmidt <ryandes...@macports.org> wrote:
> 
> 
>> On Oct 7, 2016, at 2:18 PM, Christopher Jones <jon...@hep.phy.cam.ac.uk> 
>> wrote:
>> 
>> 
>>> On 7 Oct 2016, at 8:12 pm, Ryan Schmidt <ryandes...@macports.org> wrote:
>>> 
>>> 
>>>>> On Oct 7, 2016, at 1: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.
>>> 
>>> Rainer and Clemens looked into this and got it up and running on our test 
>>> installation.
>>> 
>> 
>> So what exactly does this mean ?
> 
> It means you will log in to our Trac installation using your GitHub 
> credentials, instead of via Mac OS Forge credentials as it is now.
> 
> 
>> 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).
> 
> There will be no syncing of anything between GitHub pull requests and Trac 
> tickets because they are different entities. Trac tickets are where bug 
> reports and other issues will be filed. Currently, if someone has a fix for 
> an issue, they would attach a patch to the Trac ticket; in future, they will 
> instead open a GitHub pull request and paste a link to the pull request into 
> the ticket (or paste a link to the Trac ticket into the pull request; I'm not 
> sure if we've decided that detail yet).

At my work we use gitlab and Jira in a similar way, but there is automatic 
links between the two, in that if i quote a jira id in a git lab merge request, 
links between the two is produced automatically. Having to do this by hand 
strikes me as potentially error prone and a little cumbersome.

> And as Rainer said, there may be some simple changes for which it is 
> sufficient to just submit a pull request, without opening a corresponding 
> Trac ticket. We haven't defined what those situations would be yet.

I would hope that for a simple updates to a port, that isn't addressing a bug 
report, then no trac ticket will required. The pull request really should be 
enough in this case, and if any discussion on the update is required it can 
occur in the pull request. If during the course of that discussion it 
transpires the update needs more work, then fine a trac ticket could be opened 
at that point. But  would hope for most it would simply not be necessary, and 
if it where a requirement to always do this i think that would be an 
unnecessary overhead.

Cheers Chris


> 
> 

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

Re: Issues with oudated ports / GitHub

[Chris Jones]

> On 7 Oct 2016, at 6:08 pm, Daniel J. Luke  wrote:
> 
> On Oct 7, 2016, at 11:59 AM, Marcel Bischoff  wrote:
 It pains me to say that Homebrew is running circles around MacPorts in
 the department of current available packages.
>>> 
>>> [citation needed] ;-)
>> 
>> Gladly. I have written a small script to check that. Here are a few of
>> the results (of some tools I work with/run on a daily basis):
>> 
>> ghc
>> MacPorts version: 7.8.3_4
>> Homebrew version: 8.0.1
> 
> https://trac.macports.org/ticket/48899
> 
> I don't see a patch attached there, but I imagine one could look at the 
> homebrew recipe and pull out what is necessary?
> 
>> fontforge
>> MacPorts version: 20120731_3
>> Homebrew version: 20161001
>> pandoc
>> MacPorts version: 1.12.4.2_1
>> Homebrew version: 1.17.2
> 
> both of these are nomaintainer - we'd be happy to have you maintain the ports 
> if you're interested in keeping them updated
> 
>> mutt
>> MacPorts version: 1.6.0_1
>> Homebrew version: 1.7.0
> 
> % port info mutt
> mutt @1.6.0_1 (mail)
> Replaced by:  neomutt
> 
> Description:  This port has been replaced by neomutt.
> Homepage: https://www.macports.org/
> 
> Platforms:darwin
> License:  unknown
> Maintainers:  nomaintai...@macports.org
> 
> (neomutt is @20161002)
> 
>> boost
>> MacPorts version: 1.59.0_2
>> Homebrew version: 1.62.0
>> 
>> fdupes
>> MacPorts version: 1.51
>> Homebrew version: 1.6.1
>> 
>> imapsync
>> MacPorts version: 1.684
>> Homebrew version: 1.727
>> 
>> notmuch
>> MacPorts version: 0.22.2
>> Homebrew version: 0.23
>> 
>> sqlmap
>> MacPorts version: 0.9_1
>> Homebrew version: 1.0.10
> 
> (I'm too lazy to look up why all of these might not be up to the current 
> version - hopefully you've opened tickets [with patches wherever possible] on 
> any of these you care about).
> 
 If time and manpower is the problem, wouldn't it be better to move to a
 GitHub-based approach like Homebrew does?
>>> 
>>> That doesn't necessarily fix the problem. It's worth noting that there 
>>> already is a plan to transition to github.
>> 
>> Why is that?
> 
> 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.

Chris

> 
>> Also: what do you think the problem actually is and how to
>> rectify it? I'd be very interested to hear that.
> 
> I'm not convinced there's a general problem (other than the continual need to 
> try to get more people involved in the project).
> 
 This way far more people would
 contribute.
>>> 
>>> hopefully that's true, but there's no evidence to support that assertion at 
>>> this time.
>> 
>> Comparing the contribution rate of Homebrew to that of MacPorts, it
>> certainly wouldn't hurt things.
> 
> I'm not aware of anyone who has actual numbers on this (keeping in mind that 
> the respective user communities are different sizes).
> 
>> On the contrary. Plus, you are just
>> stating the obvious: something has not been done in an exact way,
>> therefore there is no evidence that this exact way yields this exact
>> result. Duh.
> 
> I'll be very pleased if you're right and that moving to GitHub will bring in 
> a large volume of (new) high-quality submissions.
> -- 
> Daniel J. Luke
> 
> 
> 
> ___
> 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: Working with Git

[Chris Jones]

On 07/10/16 17:39, Craig Treleaven wrote:



On Oct 7, 2016, at 12:16 PM, Sterling Smith <smit...@fusion.gat.com> wrote:


On Oct 7, 2016, at 7:20AM, Chris Jones <jon...@hep.phy.cam.ac.uk> wrote:


My point still stands though, you have to actively try the things you need to 
do, to get used to them.

+1


Yabut, then you hear things like “use —force when you need”, except then you 
hear “—force can really screw things

 up”.  I’m a little gunshy of that screw-things-up part!

Indeed, I was a little dubious of the suggestions that involve -force. I 
suspect there are better ways of working that should avoid the need for 
that.


Chris



Craig



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

Re: Working with Git

[Chris Jones]

Hi,


There will always be problems with the transition to GitHub that can be
discussed on the mailing list to find a common solution. Then it can be
documented to point people to that if they have the same problem.


Yes. But I want to at least know how to perform the tasks that I currently 
perform with Trac and Subversion once we move to GitHub. I currently do not 
feel that I understand how to do that, and worry that I and other contributors 
who do not know Git very well will no longer be able to contribute effectively 
once we switch.


My experience with moving from subversion to git is you can read about 
it as much as you want, but there is no substitute for just starting to 
try and use it. It takes a little time to get used to, but once you do 
you will not go back to svn.


So whilst I understand you want to try and work everything out up front, 
before hand, in practice I think you have to expect a bit of a learning 
curve for everyone at first, and basically just dive in and make the change.


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

Re: Working with Git

[Chris Jones]

On 06/10/16 12:15, Ryan Schmidt wrote:

On Oct 6, 2016, at 06:09, Chris Jones <jon...@hep.phy.cam.ac.uk> wrote:





On 06/10/16 11:43, Mojca Miklavec wrote:
On 6 October 2016 at 09:39, Chris Jones wrote:

How do I take the user's pull request, make additional changes, and commit
them to our master?


Anyone can commit to the branch created by the user for the pull request. So
you can just checkout that branch yourself, make changes, commit and push
them back to the branch, and thus the merge request.


Interesting, thank you, I didn't know (or think of) that.

My next question was going to be: what happens when user submits a
pull request that needs quite a bit of editing? Say that the user
first changes all the whitespacing together with content changes and
potentially does some other mistakes like increasing epoch for no good
reason etc. Of course he can then make another commit that changes
that back, but we would end up with super weird history for no good
reason unless we take the liberty to modify the commits (heavily)
before accepting them.


I guess one option would be to reject the request, providing information on 
why, and leave it to the user to fix the issues and resubmit a new request. If 
they need to they can rebase/revert their local checkout back to before their 
changes, to remove the bad commits from the history.


I assumed that in such a case, where the contributor is (or we are) making several 
commits to fix mistakes in a submission, we would use a "squash merge" (?) to 
combine all the changes in the pull request into a single commit on master. The GitHub 
web interface provides an option for this. If we want to rebase instead of merge (?) we 
would need to write up a procedure for how that's accomplished.



yeah, that is probably better. Simpler for the user at least.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Chris Jones]

On 06/10/16 11:43, Mojca Miklavec wrote:

On 6 October 2016 at 09:39, Chris Jones wrote:

How do I take the user's pull request, make additional changes, and commit
them to our master?


Anyone can commit to the branch created by the user for the pull request. So
you can just checkout that branch yourself, make changes, commit and push
them back to the branch, and thus the merge request.


Interesting, thank you, I didn't know (or think of) that.

My next question was going to be: what happens when user submits a
pull request that needs quite a bit of editing? Say that the user
first changes all the whitespacing together with content changes and
potentially does some other mistakes like increasing epoch for no good
reason etc. Of course he can then make another commit that changes
that back, but we would end up with super weird history for no good
reason unless we take the liberty to modify the commits (heavily)
before accepting them.


I guess one option would be to reject the request, providing information 
on why, and leave it to the user to fix the issues and resubmit a new 
request. If they need to they can rebase/revert their local checkout 
back to before their changes, to remove the bad commits from the history.




Mojca


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

Re: Working with Git

[Chris Jones]

On 06/10/16 10:19, Ryan Schmidt wrote:



On Oct 6, 2016, at 4:02 AM, Chris Jones <jon...@hep.phy.cam.ac.uk> wrote:



On 06/10/16 10:00, Ryan Schmidt wrote:



On Oct 6, 2016, at 3:59 AM, Chris Jones <jon...@hep.phy.cam.ac.uk> wrote:

Hi,

The instructions at

https://trac.macports.org/wiki/WorkingWithGit

seem a little out of date w.r.t. forking. It says

"To do that, go to ​https://github.com/macports/ports/ and click the fork button at 
the top right."

but ​https://github.com/macports/ports/ does not exist, it gives a 404 error...


Not out of date; rather, anticipating repositories which will exist in the 
future.


So where do I go right now, to fork things ?

git clone g...@github.com:macports/ports.git # or
git clone https://github.com/macports/ports.git # if SSH does not work on your 
network

Also give similar errors...


You can't; we haven't converted to git yet.


My mistake. I thought we had SVN mirroring in place.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Chris Jones]

On 06/10/16 10:00, Ryan Schmidt wrote:



On Oct 6, 2016, at 3:59 AM, Chris Jones <jon...@hep.phy.cam.ac.uk> wrote:

Hi,

The instructions at

https://trac.macports.org/wiki/WorkingWithGit

seem a little out of date w.r.t. forking. It says

"To do that, go to ​https://github.com/macports/ports/ and click the fork button at 
the top right."

but ​https://github.com/macports/ports/ does not exist, it gives a 404 error...


Not out of date; rather, anticipating repositories which will exist in the 
future.


So where do I go right now, to fork things ?

git clone g...@github.com:macports/ports.git # or
git clone https://github.com/macports/ports.git # if SSH does not work 
on your network


Also give similar errors...

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

Re: Working with Git

[Chris Jones]

Hi,

The instructions at

https://trac.macports.org/wiki/WorkingWithGit

seem a little out of date w.r.t. forking. It says

"To do that, go to ​https://github.com/macports/ports/ and click the 
fork button at the top right."


but ​https://github.com/macports/ports/ does not exist, it gives a 404 
error...


Chris

On 06/10/16 09:44, Ryan Schmidt wrote:




On Oct 6, 2016, at 03:32, Chris Jones <jon...@hep.phy.cam.ac.uk> wrote:




On 06/10/16 09:22, Ryan Schmidt wrote:

On Oct 6, 2016, at 02:33, Sterling Smith <smit...@fusion.gat.com> wrote:

Ryan,


On Oct 5, 2016, at 7:53PM, Ryan Schmidt <ryandes...@macports.org> wrote:

Suppose a user submits an update to a port.

With Subversion, the user would submit a patch in a Trac ticket. To test it, I 
would download the patch and apply it to my local Subversion working copy. If I 
like it, I commit it. If I don't like it, I give feedback to the user in the 
ticket, or I edit the Portfile further and commit it, then tell the user in the 
ticket what changes I made.

How will this work on GitHub?

The user will submit a pull request. How do I test it locally?

You test their changes by checking out their branch on your system.  Most 
likely they are on their own fork, and you will need to add their fork as a new 
remote

git remote add  

before checking out their branch by issuing

git checkout   # Note that this can fail if more than one remote has 
the same branch name (such as master...), and there is a more verbose way to indicate 
from where to check out the branch


Can you or someone please add this to the WorkingWithGit wiki page?

Sounds like the list of remotes is going to get unwieldy. How should one keep 
it sane?


Just through good management. Each MR needs its own branch. That branch can 
either be on a remote repo, or (if the project allows) a branch on the main 
repo. Once a MR is merged, the source branch can be deleted.


When you say "MR", you mean merge request, aka pull request in GitHub 
terminology?

I understand that a pull request should begin its life in a branch created 
specifically for this purpose, in a fork of the repo. That's up to the person 
submitting the PR to get right.

I'm talking about how I, as a MacPorts committer, will review, accept and 
otherwise deal with PRs sent by non-committers.



What if the pull request is incomplete? I know I can tell the user what's 
wrong, and they can push another commit to the same branch they made to 
initiate the pull request, and those new commits will automatically appear in 
the pull request, and I can then merge it if I like it.

Yep.

But what if the user does not respond and fix the changes? What if the user 
makes additional commits but they're still not sufficient? How do I take the 
user's pull request, make additional changes, and commit them to our master?

Instead of committing to master, you should commit to the user's fork/branch to 
add your changes to the pull request,


I did not know that was possible. Who is able to commit to a fork? I presume 
only the person who made the fork, and committers of the original repo. If 
that's true, then how would a second non-committer contribute to and improve 
the first non-committer's fork / pull request?


It depends how the owner of the fork has set up their repo.


I did not know there was any way to "set up" a fork. What is there to do, other than 
click the "fork" button on the GitHub web site?


It gets simpler (in my view) if you take merge requests from a temporary branch 
on the main repo, as then anyone who is able to create MRs can commit to other 
ones.


Committers can certainly create branches in the official MacPorts repositories. 
With Subversion, committers generally just commit to trunk. We haven't yet 
defined any policies for whether to continue that on GitHub or to encourage the 
use of branches more.

But we also accept contributions from non-committers. I want to make sure I 
understand how that will work.



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

Re: Working with Git

[Chris Jones]

On 06/10/16 09:22, Ryan Schmidt wrote:

On Oct 6, 2016, at 02:33, Sterling Smith  wrote:


Ryan,


On Oct 5, 2016, at 7:53PM, Ryan Schmidt  wrote:

Suppose a user submits an update to a port.

With Subversion, the user would submit a patch in a Trac ticket. To test it, I 
would download the patch and apply it to my local Subversion working copy. If I 
like it, I commit it. If I don't like it, I give feedback to the user in the 
ticket, or I edit the Portfile further and commit it, then tell the user in the 
ticket what changes I made.

How will this work on GitHub?

The user will submit a pull request. How do I test it locally?

You test their changes by checking out their branch on your system.  Most 
likely they are on their own fork, and you will need to add their fork as a new 
remote

git remote add  

before checking out their branch by issuing

git checkout   # Note that this can fail if more than one remote has 
the same branch name (such as master...), and there is a more verbose way to indicate 
from where to check out the branch


Can you or someone please add this to the WorkingWithGit wiki page?

Sounds like the list of remotes is going to get unwieldy. How should one keep 
it sane?


Just through good management. Each MR needs its own branch. That branch 
can either be on a remote repo, or (if the project allows) a branch on 
the main repo. Once a MR is merged, the source branch can be deleted.





What if the pull request is incomplete? I know I can tell the user what's 
wrong, and they can push another commit to the same branch they made to 
initiate the pull request, and those new commits will automatically appear in 
the pull request, and I can then merge it if I like it.

Yep.

But what if the user does not respond and fix the changes? What if the user 
makes additional commits but they're still not sufficient? How do I take the 
user's pull request, make additional changes, and commit them to our master?

Instead of committing to master, you should commit to the user's fork/branch to 
add your changes to the pull request,


I did not know that was possible. Who is able to commit to a fork? I presume 
only the person who made the fork, and committers of the original repo. If 
that's true, then how would a second non-committer contribute to and improve 
the first non-committer's fork / pull request?


It depends how the owner of the fork has set up their repo. It gets 
simpler (in my view) if you take merge requests from a temporary branch 
on the main repo, as then anyone who is able to create MRs can commit to 
other ones.






and then you might ask another committer to look over your work and make the 
final merge to master, or if you are above review, you could just merge your 
work yourself.


For major changes yes some review process might be nice. We'll need to work 
that out after we move. We don't have a formal review process for that kind of 
thing today.


Clemens, in your repository here, you committed something I had previously 
committed in a fork, but had not submitted a pull request for:

https://github.com/neverpanic/macports-svn2git-rules/commit/bfeed37956f72bf996865e414a375128186d1adf

The GitHub interface says "ryandesign committed with neverpanic". How did you 
cause that notation to appear, and is that something we should be using in our MacPorts 
git workflow?

git keeps track of both author and committer (also sign-off?).  When you commit some 
change for the first time, then you are added as author and committer.  If a person 
cherry-picks or uses rebase to incorporate some commit into a branch, then the committer 
is changed to the person that applied the cherry pick or rebase.  If the author and 
committer are different, then GitHub detects that and presents the two parts as you have 
seen as "ryandesign committed with never panic".


Ok, so we don't need to do anything special; this happens automatically.



-Ryan


When is the macports repo on GitHub supposed to appear?


I have no ETA for you yet. "When it's ready." Part of being ready includes 
having documentation about how we'll perform the tasks we need to perform on GitHub, so 
people who know how to do that should definitely contribute to the documentation, and 
people should ask questions about things that aren't explained in the documentation.
___
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: Working with Git

[Chris Jones]

> How do I take the user's pull request, make additional changes, and 
commit them to our master?


Anyone can commit to the branch created by the user for the pull 
request. So you can just checkout that branch yourself, make changes, 
commit and push them back to the branch, and thus the merge request.


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

Re: Patch naming policy (was: Re: [153574] trunk/dports/sysutils/skey)

[Chris Jones]

> On 5 Oct 2016, at 2:56 pm, Rainer Müller  wrote:
> 
> On 2016-10-05 01:45, Ryan Schmidt wrote:
>>> Patches should follow the patch-*.diff naming scheme, so this
>>> should be named patch-skeyprune-man8.diff or similar.
>>> 
>>> https://guide.macports.org/#development.patches.source
>> 
>> Popular opinion seems to be that we should relax that restriction.
>> 
>> I think it's reasonable if we change it to "patch-*.diff or
>> *.patch".
>> 
>> My primary gripe was with the way patches used to be named
>> "patch-foo" or "patch-foo.c" which caused editors to use incorrect
>> syntax highlighting. As long as we use a .diff or .patch extension,
>> to indicate to a syntax highlighter that this is a diff or patch
>> file, that should be fine.
> 
> The initial patch-* policy was adopted from FreeBSD ports. The filename
> extension .diff was added later for this reason.
> 
> If we want to change the patch naming policy, should we allow both
> *.diff and *.patch or would one file extension be better to avoid
> configuring editors twice?

My bet is any decent editor, at least those which support software development, 
would already support both.

> 
> Rainer
> ___
> 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: order of operations in port upgrade

[Chris Jones]

Hi,

The current order makes more sense to me. Only clean once the activation 
is successful. I also fail to see how your proposal helps with your 
fragmentation ?


Chris


On 05/10/16 10:09, René J.V. Bertin wrote:

Hi,

Quick question: a normal (non-forced) upgrade currently does

1) install (create new tarball image)
2) deactivate old
3) activate new
4) clean ${workpath} (unless -k)

Would there be anything against exchanging ops 3 and 4?

1) install (create new tarball image)
2) deactivate old
3) clean ${workpath} (unless -k)
4) activate new

I just had a look at my workdisk in iDefrag, and free disk fragmentation is 
terrible ATM, at a point where I cannot even do a complete online defrag (= of 
unused files) due to lack of contiguous free space (yet there's over 110Gb 
free). I know this is less of an issue on SSDs yet I cannot help but think that 
free disk fragmentation ends up being a PITA everywhere. The proposed change 
should help keeping it in check.

I haven't look at how trivial it would be to implement this particular change. I 
think the upgrade routine already has separate paths for normal and forced 
operation (1 & 2 being exchanged in forced mode), right?

R
___
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: Dual g++ ABI in libraries --- how to handle it?

[Chris Jones]

> On 4 Oct 2016, at 3:35 am, Alexander Gaenko  wrote:
> 
> Hi,
> 
> The build of our C++ library
> (https://www.macports.org/ports.php?by=name=alpscore) fails
> with g++-mp-6 --- apparently due to the fact that Boost libraries used
> by our code were compiled with the "old" pre-C++11 ABI, and g++ >=5.1
> by default compiles using the "new" ABI.
> 
> I know that it is possible to compile our library with the "old" ABI
> by defining "_GLIBCXX_USE_CXX11_ABI=0".  But this would force any code
> that links with our library to use the "old" ABI, too.
> 
> This situation could be remedied by using Boost variant compiled with
> the "new" ABI --- however, there seems to be no such variant in the
> Boost port.
> 
> The question: what is the current/recommended way to handle this
> "old"/"new" ABI transition?
> Do all C++ libraries ports that use Boost set ABI to "old"?

Do not use FCC to build your library, as this will end up with mixed c++ 
runtimes. Use the same compiler as mac ports uses, which for recent OS X 
versions will be the system clang++ compiler.

> 
> Thank you,
> With best regards,
>   Alexander.
> ___
> 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: weird (buggy?) build dependency on a clang port

[Chris Jones]

Because macports-clang-3.7 occurs first in the fallback list. Print out
${compiler.fallback} if you don't believe me. :)

Installed compiler ports are not considered "more available" than
uninstalled ones.


Which of course is a good thing. A port installation should be fully 
reproducible. For a given OSX (and perhaps Xcode version), the same 
compiler should be used always, it should not depend on what the user 
happened to have installed.


Chris




- Josh
___
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: How to discontinue ports completely (py26 deprecation) ...

[Chris Jones]

On 11/08/16 20:40, Fred Wright wrote:



On Wed, 10 Aug 2016, Lawrence Velázquez wrote:


On Aug 10, 2016, at 5:21 PM, Fred Wright  wrote:


I don't consider Python 2.6 to be "cruft".  Developers need many
versions of Python installed for testing, and that includes any
packages that are also needed.  It's annoying to have to create local
versions of portfiles solely to add versions that are missing for no
substantive reason.


The substantive reason is that every additional version of CPython we
support is a maintenance burden, especially one that saw its last
feature release 6 years ago and its last bugfix release nearly 3 years
ago.


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 ?


Chris



BTW, there's some erroneous information that making code compatible with
both Python 2 and Python 3 requires 2.7.  I have yet to encounter any
issues with "polyglot" code per se on Python 2.6.  Anything earlier is
definitely problematic, however.

Fred Wright
___
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: port:libclang (and libLLVM)

[Chris Jones]

> On 9 Mar 2016, at 5:08 pm, René J.V. Bertin  wrote:
> 
>> On Wednesday March 09 2016 08:41:56 Eric A. Borisch wrote:
>> 
>> FWIW, if compressed with HFS+ compression (afsctool with -f -6 -s 50
>> options, for reference), llvm-3.7 and clang-3.7 combined take 756MB rather
>> than 3.4+ GB.
> 
> I use a patched portimage.tcl that uses bsdtar from port:libarchive which 
> supports the --hfsCompression argument. I know the gain can be significant, 
> but never calculated it precisely.
> 
> Regardless, >700Mb is still a far cry from (>10x) what I've seen cited for 
> just libclang.
> 
>> One potential port that comes to mind would be cling
>> as dependency of (= part of) ROOT 6, but I would imagine that it would
>> need quite a bit of effort before ROOT and/or cling could simply
>> depend on "libclang"
> 
> Looks like "Cling is an interactive C++ interpreter, built on the top of LLVM 
> and Clang libraries" but is built inside *a* llvm+clang tree hosted by the 
> CERN and having a dedicated branch called cling-patches. That does seem to 
> make it a bit unlikely that one day cling could build against a stock 
> libclang ...

Well, that is true but i also know that the root team always looks to push as 
much as it can upstream, and very much work with the clang developers. So, yes, 
at the moment there are a number of patches applied, but that doesn't mean at 
some point in the future they would be removed. But i think the root team have 
a number of much more pressing things to fix first (like gcc 5 support. 
Currently on linux clang cannot be built and run against the gcc5 abi), and 
ultimately the root team might decide they only wish to support build their own 
internal clang version, for various reasons (the one you mention below for 
instance being one.)

> 
> Another potential candidate for which I already have a personal port is 
> clazy: https://www.kdab.com/use-static-analysis-improve-performance/
> 
> 
> About libLLVM: I'm told that libclang's dependency on libLLVM happens "when 
> you build enable shared libraries for libLLVM. This is not good for 
> performance, and should not be done when you want to create a libclang for 
> redistribution purposes."
> 
> I've heard that before, and wonder if it's the reason clang-mp-x.y has always 
> been up to 2x slower than equivalent Apple builds (and not just for me).
> 
> Is there a reason the LLVM ports build a shared libLLVM?
> 
> R.
> ___
> 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: port:libclang

[Chris Jones]

Hi,

As far as I am aware ROOT6 does not offer any build option to use an 
external clang installation. It always builds its own internal version, 
and I would not be in favour of MacPorts changing this until such a time 
as upstream offers it as an officially supported option. Not that I am 
against a libClang, I can see the usefulness, but I don't really see 
ROOT6 using it any time soon.


Chris

On 09/03/16 12:23, Mojca Miklavec wrote:

On 9 March 2016 at 13:13, René J.V. wrote:


I have no idea how many (potential) ports (could) use and benefit from a 
port:libclang-x.y but would it be possible to create such (sub)ports?


One potential port that comes to mind would be cling
 https://root.cern.ch/cling
as dependency of (= part of) ROOT 6, but I would imagine that it would
need quite a bit of effort before ROOT and/or cling could simply
depend on "libclang". It's probably not easily doable at this very
moment yet (but I don't know the details anyway).

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

Re: where Xcode 3.1 / command line tools ...

[Chris Jones]

On 24/02/16 15:13, Brandon Allbery wrote:

On Wed, Feb 24, 2016 at 10:12 AM, Chris Jones <jon...@hep.phy.cam.ac.uk
<mailto:jon...@hep.phy.cam.ac.uk>> wrote:

Been ages since I ran 10.6, so I might have forgotten where things
are in that OS, but have you checked the OSX App Store for Xcode ?


Xcode before 4.0 was not available via the App Store, as it installed
under /Developer instead of as a standalone app bundle.


Fair enough...

According to

http://guide.macports.org/#installing.xcode

Xcode for OSX10.6 is available via the developer website, and indeed if 
I followed the link in the above I was able to find it pretty easily... 
Just search for 'Xcode 3'


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

Re: where Xcode 3.1 / command line tools ...

[Chris Jones]

Been ages since I ran 10.6, so I might have forgotten where things are 
in that OS, but have you checked the OSX App Store for Xcode ?


On 24/02/16 15:08, petr wrote:


Hi I am trying to install Macports on an old OS X 10.6 system, but have 
difficulties to get/find Xcode 3.1 and the command line tools. Is there a place 
where they can be downloaded.

I have a ADC account and I used to find them there, but this seems not to be 
possible any more. Any tips?

Thanks a lot!
~petr

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


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

Re: VLC cannot play MKV files?

[Chris Jones]

Hi,


On 26/01/16 09:47, Vincent Habchi wrote:

I was under the impression that Apple already compressed the files and programs 
installed with the operating system, using HFS compression, ever since taking 
up less disk space was listed as a feature of Snow Leopard.

Yeah, I thought so too, but I also have the impression that may not always work 
as advertised after a few updates have been applied. Easy enough to check with 
`ls -lO` (/usr/bin/ls that is).


I’ve applied René method, disabling SIP while compressing /Applications. It 
gave me some significant savings, thus I surmise all the applications are not 
compressed. Xcode is, though, but things like iWorks (Pages, etc.) are not.

I am not space savings in Snow Leopard were the result of using file 
compression. I’d rather wager Apple get rid of some universal code (ppc/ppc64) 
in 10.6. 10.5 was the final version usable with ppc, AFAIR.


I have in the past used Xslimmer to save a fair amount of space on old 
OSX versions where PPC versions etc. where still shipped.


http://www.xslimmer.com/

With it you can slim down fat binaries to the exact version you require 
(PP, 32bit, 64bit) but also remove, if you want, all the 
internationalization a lot of applications come with. Some applications 
can really be reduced in size...


Chris

p.s. I have nothing to do with them...



Vincent

___
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

OSX 10.11 buildbot status ?

[Chris Jones]

Hi,

Just curious, but whats the status of getting a buildbot for 10.11 set up ? 
Would be good to start proving binary tarballs for this platform.

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

Re: Plan B?

[Chris Jones]

On 12/10/15 16:25, Mojca Miklavec wrote:

On Mon, Oct 12, 2015 at 4:59 PM, Mark Anderson wrote:

I dunno, but it seems like we're easily the most active project on here.
Followed by XQuartz maybe.


Webkit seems to be hosted on Mac OS Forge as well and it seems
relatively active:
 https://www.webkit.org/meeting/

A few other projects I checked are also 10.11-ready.

I would prefer to stay where we are now, but it would be nice to have
backups, even if just to be able to point people to a read-only mirror
of trac (if trac is down), main website, SVN, ... for example.


https://archive.org/web/ does a reasonable job at this. Thats what I was 
using anyway over the weekend whilst trac was down.






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

ROOT6 Update commit

[Chris Jones]

Hi,

Could I ask someone to take a look at

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

to review for committing ?

many thanks

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

Re: avoid usage of Macport installed software

[Chris Jones]

 On 7 May 2015, at 5:48 pm, petr 9...@ingv.it wrote:
 
 
 Hi all,
 
 I am working on some new port. It works already quite fine, but I observe 
 that when using it without Tracemode, it would pick up various already 
 installed programs. Most of these are also provided by Xcode, but notably 
 when `doxygen` is picked up, it also creates some extra documentation. This 
 all works smoothly, but it would not create a consistent build across various 
 installs. Is there a canonical way to avoid such problems?

If these dependencies add additional useful featured, then why not just make 
your port depend on the MacPorts versions of them (assuming they exist of 
course). Then you get the repeatable builds as well as those added features. 
Better yet, make those dependencies something that can be turned on and off via 
variants (particularly if the dependencies list is long such that you might not 
want them by default). Then users can decide. Of course, this also requires the 
ability to turn off support in your port. This is something that depends on the 
build system your port uses, and what options that has to do this. 

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

Re: Port xapian-bindings' dependency on MacPorts' (outdated) ruby port

[Chris Jones]

On 16/04/15 09:40, René J.V. Bertin wrote:

On Thursday April 16 2015 08:54:30 Chris Jones wrote:


If the port needs ruby it should depend on a macports ruby version and
not rely on the system one, regardless of what version the system one
is. This is normal macports behavior, to provide a standard version
across all OSX versions.


It also leads to a profusion of additional ports and dependencies to maintain, 
and periodic update nightmares just because the default python/perl/ruby 
version has been updated. This is all the more annoying if we're talking about 
a build dependency on python/perl/ruby.
What would be the implications of providing (say) variants that leverage the 
system python/perl/ruby, other than the obvious loss of binary packages?
Have there been known instances of a major python/perl/ruby version update in 
an OS update (as opposed to upgrade)?


As far as I am concerned

https://trac.macports.org/wiki/FAQ#ownlibs

answers why not quite well. I see no reason to do anything differently 
for ruby.



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

Re: Port xapian-bindings' dependency on MacPorts' (outdated) ruby port

[Chris Jones]

On 16/04/15 08:18, Marko Käning wrote:

Hi,

I am trying to make use of xapian-bindings, which has a dependency on MacPorts'
ruby, which currently results in version 1.8.7
---
$ ruby --version
ruby 1.8.7 (2013-06-27 patchlevel 374) [i686-darwin13]
---

Now I ask myself, whether this port deliberately asks for this old version, or
whether one perhaps could drop this dependency altogether, as I am obviously
having ruby installed natively in a much newer version on 10.9 and 10.10:


If the port needs ruby it should depend on a macports ruby version and 
not rely on the system one, regardless of what version the system one 
is. This is normal macports behavior, to provide a standard version 
across all OSX versions.


Instead, why not update its dependency to one of the newer ruby ports 
macports provides. There are several, going up to 2.2.X


ruby19 @1.9.3-p551 (lang, ruby)
Powerful and clean object-oriented scripting language

ruby20 @2.0.0-p643 (lang, ruby)
Powerful and clean object-oriented scripting language

ruby21 @2.1.5 (lang, ruby)
Powerful and clean object-oriented scripting language

ruby22 @2.2.1 (lang, ruby)
Powerful and clean object-oriented scripting language

Chris

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

Re: expecting a user to use `port select` from a Portfile (re: Qt 5 support on OS X 10.6)

[Chris Jones]

On 27/03/15 11:05, René J.V. Bertin wrote:

Hello,

I've managed to get Qt 5.3 to build on OS X 10.6 and adapt my qt5-mac-devel 
Portfile for that. No small feat, as this is not officially supported by Digia. 
Main issue here: the system compilers on 10.6 (*gcc-4.2, and clang from Xcode 
3.2 as well as Xcode 4.2) are incapable of building Qt 5.3 and care must thus 
be taken not to use them accidentally.

This requires a modern version of clang, and in order to avoid ending up with a 
hard-wired clang version dependency my current approach instructs the user to 
use `port select` (or equivalent). The actual requirement is to have a modern 
compiler in the path (I've only tested with clang because that's what Qt 5.3 
builds with on supported OS X versions). My own requirement is that there be no 
version information in the compiler name, in order to avoid said hard-wired 
dependencies and unnecessary rebuilds.

I caught flak on my trac ticket for requiring port select, despite IMHO 
conforming to its intended use, i.e. user convenience. This requirement takes the form of 
testing for ${prefix}/bin/clang{,++} and aborting with instructions if those items are 
missing. Those would normally be one-time instructions, of course.

What other approaches are there? I can only see a few

- Change the rewriting of several Qt build script/config files so that they 
don't contain a full path to ${prefix}/bin/clang{,++}, presume that 
${prefix}/bin will always and reliably be first in the path, and cross eyes, 
fingers and toes that everything builds correctly. Qt and Qt applications alike.

- Hack the build system even more in order to provide a Qt-specific equivalent 
for the port select mechanism.

- Drop the idea of supporting OS X 10.6 in an official port


How does requiring 'port select' to have been run work with the 
buildbots, where this cannot be done ? Personally, I agree with the 
comments that this is not something you should be requiring.


IMHO, if upstream have 'officially' dropped support for OSX10.6, then 
this is not something MacPorts ports should second guess, so my 
preference would be for the 3rd option, just drop support. This is what 
I did with the root6 port, which had a similar issue.


cheers Chris



If I'm missing something obvious and more elegant than asking the user to use 
`port select` I'd love to hear about it, but as things stand I think it's the 
best compromise that doesn't even violate official dogma.

BTW, it would also be about time to publish this port (and qt4-mac) so that 
more users can start installing and testing Qt4 and Qt5 applications alongside.

The current port directory: 
https://trac.macports.org/attachment/ticket/46536/port%3Dqt5-mac-devel.tar.bz2

R.
___
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: standard way to require c++11?

[Chris Jones]

On 19/03/15 18:44, Michael Dickens wrote:

On Thu, Mar 19, 2015, at 02:06 PM, Lawrence Velázquez wrote:

On Mar 19, 2015, at 1:56 PM, Michael Dickens michae...@macports.org
wrote:

Exactly. If we key off of {${configure.cxx_stdlib} eq libstdc++}, then
I think this can be made to work; er, mostly.


I believe this is only safe if you're absolutely sure that all the C++
objects your code uses or links with uses MacPorts' libstdc++ /
libc++.


I know it is possible to select configure.stdlib on a per-port basis ...
but, it's certainly not wise in general  how many folks or ports really
-try- to do this? I know it fails for me (on 10.8 and 10.10:
cross-linking libc++ and libstdc++ from Apple and MacPorts) way more
often than it works, so I just don't do it. I don't really see this as a
major issue, given how well it doesn't work. - MLD


Using Macports gcc you will still have the problem of mixing different 
C++ runtimes, the macports stdlibc++ used by the gcc ports, and the 
system one. They are not the same and if you try use at the same time 
ports built with the normal compiler, to yours, problems can happen.


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

Re: standard way to require c++11?

[Chris Jones]

On 19/03/15 17:54, René J.V. Bertin wrote:

On Thursday March 19 2015 17:01:02 Chris Jones wrote:


Using gcc is a bad idea, this can lead to C++ runtime issues.


On newer OS X versions where libc++ is the default (or only) C++ runtime.


No, its problematic on all OSX releases.




Which means newer systems use the compatible system clang compiler, and
older system use the macports clang compiler. I think this is the 'best
effort' solution. It doesn't work on OSX10.6 though, there we simply
given up support, as least with the root6 port.


I don't see what's against using port:gcc4x on 10.6 or 10.7 as long as you 
don't need Apple-specific compiler extensions (probably including universal 
builds).


IFAIU, its still a problem as you will then be mixing the libstdc++ from 
macports with the system one. Not as bad as mixing libc++ with 
libstdc++, but still far from ideal and can lead to problems.


It's how I built relatively complex ports like kdevplatform and 
kdevelop, without any issues. Oh, and (favourite topic of mine), it's 
also a lot faster than the clang ports O:-)


Speed is not a concern for most, as they get most ports via the binary 
tarballs, and who cares how long it takes on the buildbots ;)


Speed also should never trump correctness, and again AFAIK, its more 
correct to use Macports clang in these cases, than macports GCC.


Chris


I've never managed to use the blacklisting feature to force port to use 
g++-mp-4.{7,8,9}, though.

R.
___
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: standard way to require c++11?

[Chris Jones]

Hi,

The bottom line is there is no clean way of supporting C++11 on 10.8 or 
older. Its can only be done on a best try basis.


Using gcc is a bad idea, this can lead to C++ runtime issues.

In the root6 port we use

# Force a compatible compiler
compiler.blacklist-append *gcc* {clang  500} macports-clang-2.9 
macports-clang-3.0 macports-clang-3.1 macports-clang-3.2

compiler.fallback-append macports-clang-3.4 macports-clang-3.5

Which means newer systems use the compatible system clang compiler, and 
older system use the macports clang compiler. I think this is the 'best 
effort' solution. It doesn't work on OSX10.6 though, there we simply 
given up support, as least with the root6 port.


Chris

On 19/03/15 16:04, Michael Dickens wrote:

I have a few ports that have recently moved to requiring c++11 (or,
maybe, c++0x), and a few to-be-submitted ports that do too, so I'm
wondering if there's a standard way to specify this requirement -- for
example, something like:
{{{
PortGroup   compilers 1.0
compilers.setup  require_cxx11
}}}
and, then port does the right thing by selecting the compiler and
cxxflags no matter the OS.

I did a quick search through the dports tree, and couldn't come up with
a single standard way to do this. The closest I found was something
like:
{{{
 PortGroup compiler_blacklist_versions 1.0
 compiler.blacklist-append *gcc-4.0 *gcc-4.2 {clang  300}
}}}
but, the above does not work on my 10.8 install.


From what I can gather via testing on my 10.8 install, the clang ports

support -std=c++11 only when -stdlib=libc++ -- which is not the
default in MacPorts for 10.8 and prior. I haven't tried moving my ports
install to using libc++, instead leaving it with the default. Hence, it
looks like I'm stuck using GCC.

GCC 4.7+ do provide full support for -std=c++11, and it looks like GCC
4.[56] provide support for -std=c++0x (but, that's old enough now that
I think I can just limit support to actual c++11).

Anyway, wondering how others have provided c++11 support to the variety
of OSs MacPorts supports. Thanks! - MLD
___
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: port upgrade outdated order

[Chris Jones]

On 04/03/15 15:57, Mihai Moldovan wrote:

On Wednesday March 04 2015 08:58:17 Chris Jones wrote:

ports themselves cannot opt in or out, and nor should they be able to.
Its up to the user running the port command to decide.

That's too dogmatic. I have presented a case where the options are
either using trace mode to successfully build ports (ports in the
conflicts_build group which conflict with themselves) or fail. In that
case, trace mode has to be forced for this particular port if no
preference has been specified. If the user explicitly disables trace
mode via a command line switch (which does not exist yet, as it's not
the default option or even one that could be enabled within
ports/portgroups...), execution will fail like it does today, but the
request should be honored.


OK, I'll rephrase then. It seems OK for a port to opt into tracemode, if 
needed to fix bugs like this, but if the user has tracemode globally 
disabled ports should not be allowed to opt out.


Personally though, I still it better to just enabled trace mode by 
default globally, which will just naturally soak up all these cases. If 
a user then decides to globally opt out, thats their concern.




I'd make one exception from this rule: a setting in macports.conf should
be overrideable by ports/portgroups (especially for the use case I
mentioned when the possible ways to go are TRACE MODE or FAIL.)
This also holds for positive settings for ports, which are known to fail
in trace mode by the maintainer.


I would argue only with the above restriction. Opting in is perhaps 
fine, but not out.


Chris



If absolutely need-be, the modes could also be force-on, on, off,
force-off, but force-on and force-off can be handled by -t (real
enable trace mode switch)/-T (currently imaginary disable trace mode
switch) just fine, so we don't need anything non-boolean in macports.conf.


On 04.03.2015 11:37 AM, René J.V. Bertin wrote:


You have a lot of faith in this mode, and the extent to which it is possible to 
let it handle each and every case appropriately for each and every (potential) 
port out there.


Yes, we do. Because trace mode is doing the right thing™. Yes, the name
is kind of misleading. It stems from the fact that it uses the
darwintrace library to implement its functionality and override
syscalls (like dtrace.)

It's really a very strict sandbox, though, not a tracing utility per se.



Maybe it is possible so there's indeed no need for allowing opt-out, but as 
Mihai also said, there are enough examples of cases where we'd want opt-in (if 
the user didn't specify a setting) or at least a warning if the user opted out 
but the port requires it.


See above.



Mihai


P.S.: could you please fix your client to not always add Undisclosed
Recipients: ;? I have to remove that every single time I answer to any
of your posts.



___
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: port upgrade outdated order

[Chris Jones]

Hi,

On 04/03/15 17:29, René J.V. Bertin wrote:

On Wednesday March 04 2015 17:34:32 Mihai Moldovan wrote:


Aren't you relying on the assumption that all ports register all the files they 
install?


They really should. If they don't, that's arguably a bug. Exceptions may
apply.


Let me clarify: do all ports register all files that are somehow related (not 
necessarily installed; possibly created afterwards, etc). This came up when we 
discussed using the archive tarballs to reinstall a port, or to recreate those 
tarballs from the currently installed stuff, and I remember there was good 
reason that ports can have associated files that are not registered.
I cannot come up with a good example right now, but I expect that there might 
be build systems (or portfiles) that use such files one way or another.


If you can come up with an example, I would again personally classify 
that as a bug in the port that should be fixed. *anything* a port 
installs should be installed during the destroot phase, and thus be 
properly registered. If there are ports that side-step this, then those 
ports are at fault.





I should add another fact to clear up some confusion: files, which are
not registered by a specific port are *not* affected by trace mode at
all. They can be accessed as-is. This also holds for symlinks that are
created by port select and the like.


Which is exactly what I was getting at. If they were inaccessible (because 
trace mode allows access only to registered files that are sanctioned 
explicitly) you'd get an error, and the missing dependency becomes apparent. If 
a port can access them (because tracemode block access only to registered files 
that are not sanctioned explicitly) trace mode doesn't help.
Granted, a marginal use case that got blown out of proportions because of an 
apparent communication glitch :)



Hmm, I did not realise this. I thought that it was the opposite way 
around, so only files explicitly registered are made visible. Whats the 
reason it doesn't work this way ? Some technical limitation or by choice 
(for some reason I don't yet see) ?


Anyway, all the more reason that if a port 'installs' files outside the 
normal MP system and thus they are not registered, that should be 
regarded as a bug in that port.


Chris


there (not provided Apple, not provided by MacPorts) in /usr/local, this
directory tree is completely shadowed.


Good. I still keep stumbling over stuff in there on my own system.

R.
___
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: port upgrade outdated order

[Chris Jones]

OK, I'll rephrase then. It seems OK for a port to opt into tracemode, if
needed to fix bugs like this, but if the user has tracemode globally
disabled ports should not be allowed to opt out.

 ^
  enabled .



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

Re: port upgrade outdated order

[Chris Jones]

On 04/03/15 17:24, René J.V. Bertin wrote:

On Wednesday March 04 2015 16:52:50 Chris Jones wrote:


If upstream cannot/wont fix, then if we want to keep the port in
MacPorts, it should be worked around. trace mode (or anything that does
the same thing, hides the installed version) strikes me as perfect here.


Agreed - and that's exactly an example of a case where some form of requiring 
trace mode in the portfile would be useful.


I think we are just niggling over the details here. I am not sure I see 
the need for ports to be able to opt in or out of tracemode (out should 
be just not possible, but I could be persuaded on opting in). For me, 
trace mode is much more than a 'debugging' tool, but a means of 
sanitising the build environment to limit the build from only having 
access to what we want.



As to fixing ... the experience many of use have had with /usr/local can 
probably serve as an example/metaphor for why it's not always feasible to avoid 
including the wrong version of a header... (and I guess it should be easier to 
exclude or demote a directory from outside the prefix than to exclude/demote 
${prefix}/include ...)


I don't see whay you say its not feasible. tracemode would absolutely 
prevent access to /usr/local during building, which is a very good 
thing. It would also only allow access to the files the ports the port 
in question being built has declared a dependency on. As MP knows 
exactly which files a given port has installed, this can be done on a 
file by file level. This should pretty well cover any use case of a port 
building against things it shouldn't, regardless of if those files are 
under /usr/local (just a blanket ban) or more fine grained control under 
${prefix}.


Chris



I wasn't completely PC about the exchange I had on the Qt ML: apparently 
attempts had been made to correct the particular issue I reported, which turned 
out to be too tricky.

R.



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

Re: port upgrade outdated order

[Chris Jones]

On 04/03/15 16:10, René J.V. Bertin wrote:

On Wednesday March 04 2015 09:26:10 Brandon Allbery wrote:


Port bugs are never OK. A diagnostic/debugging mode that is forced on in
some port as a hackaround for port bugs instead of fixing the port is
*also* never OK.


When a port fails to build because the project/package/whatever it provides 
doesn't support building with a previous version present, is that a port bug?


As far as I am concerned its a bug in the port, or a bug in the upstream 
project. Note that this is just one thing fixed by trace mode, as the 
port should then simply not see the installed older version of itself.




I see only 1 conclusion to which this sort of reasoning can lead: such ports 
should be kicked out of MacPorts...

BTW, once trace mode is made the default, it can no longer be considered a 
diagnostic/debugging mode, IMHO ...
At least not the part that blocks access to things that are not explicit 
dependencies, because in the end that has a similar effect as Debian/Ubuntu's 
build bots which create a new VM that pulls in only the required dependencies 
for every package that is built.

R.
___
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: port upgrade outdated order

[Chris Jones]

On 04/03/15 16:43, René J.V. Bertin wrote:

On Wednesday March 04 2015 16:22:16 Chris Jones wrote:


When a port fails to build because the project/package/whatever it provides 
doesn't support building with a previous version present, is that a port bug?


As far as I am concerned its a bug in the port, or a bug in the upstream
project.


I used to think like that, until I reported this kind of issue in one of Qt's 
component. It was not very delicately pointed out to me that it's common 
practice to build things without previous versions present (cf. the Debian and 
Ubuntu buildbots).

So, no, it is apparently not considered a bug if something doesn't build when a previous 
version of it is installed in the destination. And given that, one can hardly expect port 
devs to just fix this.


what upstream thinks doesn't change what I think, and that is all I was 
claiming, that *I* consider it either an upstream bug, or a port bug. We 
also don't have to agree on things ;)


If upstream cannot/wont fix, then if we want to keep the port in 
MacPorts, it should be worked around. trace mode (or anything that does 
the same thing, hides the installed version) strikes me as perfect here.


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

Re: port upgrade outdated order

[Chris Jones]

note that trace mode fixes this ;-)


How so?


By masking files that aren't part of the operating system, Xcode, or port 
dependencies.


Hmmm, can't say the term trace evokes that for me :)

I think I understood that ports can opt out from this mode, no? Can they also 
activate it?


ports themselves cannot opt in or out, and nor should they be able to. 
Its up to the user running the port command to decide.


Chris

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

Re: port upgrade outdated order

[Chris Jones]

On 04/03/15 10:37, René J.V. Bertin wrote:

On Wednesday March 04 2015 08:58:17 Chris Jones wrote:


I think I understood that ports can opt out from this mode, no? Can they also 
activate it?


ports themselves cannot opt in or out, and nor should they be able to.
Its up to the user running the port command to decide.


You have a lot of faith in this mode, and the extent to which it is possible to 
let it handle each and every case appropriately for each and every (potential) 
port out there. Maybe it is possible so there's indeed no need for allowing 
opt-out, but as Mihai also said, there are enough examples of cases where we'd 
want opt-in (if the user didn't specify a setting) or at least a warning if the 
user opted out but the port requires it.


Personally, I think what it does is *always* correct. If a port A does 
not declare a dependency on another port B then it should not be using 
any files from that port B. period. If it does, then I consider that a 
bug in port A. tracemode simply enforces this by blocking access to 
files a port should not be using, which results in more predictable 
behavior, and makes it easier to find mis-behaving ports.


So no, I don't personally think there should be a way for ports to opt 
in or out.


Chris

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

Re: port upgrade outdated order

[Chris Jones]

On 04/03/15 11:29, René J.V. Bertin wrote:

On Wednesday March 04 2015 10:51:06 Chris Jones wrote:


Personally, I think what it does is *always* correct.


Aren't you relying on the assumption that all ports register all the files they 
install?


yes. If they don't that should be regarded as a bug.

 What happens to files installed because of some port C that are used 
by port A while it builds, how are you going to block them if port C is 
not on the dependency list?


If port C is not listed as a dependency of port A, and port A then uses 
files from port C, then that is a bug in port A.



There were discussions not that long ago that showed that there are classes of 
files that get installed by ports but not registered for a reason.


So no, I don't personally think there should be a way for ports to opt
in or out.


So to you it's OK if a port fails to build because it pulls in things from an 
earlier, installed version of itself that were not blocked because the feature 
was not enabled, and do so without as much as an explanation?


Thats not what I said.

All I am saying is a port build should be *completely* reproducible and 
predictable. What happens during the build of a port should not depend 
on either anything from an older currently installed version of that 
same port, or from any ports which the port in question finds at build 
time and uses, but has not declared a dependency on.


trace mode, which blocks access to files a port should not be using 
(because they have not declared a dependency) is a great tool at 
providing this reproducibility. I do not see any use case for an 
individual port being able to by itself opt in or out of this feature, 
it should be completely up to the user running port to decide, either 
via a command line switch, or via macports.conf. I would not be in 
favour of ports being able to forcibly opt out, as the only reason for 
doing so in my opinion is because they have bugs that should instead be 
fixed.


Chris


I'd be in favour of a more pragmatic approach, and allow opt-in (require it) 
when the feature is disabled globally (in macports.conf, possibly with a 
warning), which turns to an error when the feature was disabled on the 
commandline. That's not unlike how dependencies are handled: nothing is done 
when they're already installed, they're installed when needed unless the user 
takes action to prevent that - in which case an error is raised at some point.

R.

___
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: ~/.macports

[Chris Jones]

On 12/02/15 12:13, René J.V. Bertin wrote:

On Thursday February 12 2015 12:33:53 Clemens Lang wrote:


You should be aware of the security implications of this change. For example,
sudo port edit vim gets you arbitrary code execution and arbitrary file access 
as
root.


Exactly one of the reasons I don't like rendering sudo implicit, and even less 
strip it of its pw protection.
I really prefer to take my chances making select parts of the FS writable to 
the admin group, and allow non-privileged port to write to my home directory. 
There's nothing in there that I cannot restore from backup. The same applies 
for the rest of the system, but recuperating from a borked OS or from a borked 
$HOME are not exactly comparable in terms of effort.


I would actually argue allowing port to run via sudo without requiring a 
password could be viewed as improving security. By allowing 'sudo port' 
to run without a password, you never have to authenticate, which means 
sudo never enters into its state where it can run *any* command without 
a password. This means running


 sudo port XYZ
 sudo something bad

will prompt you for a password on that second command, because the first 
does not require one. If you had to enter a password for the first 
command, then the second would just run...


Of course, if port itself is viewed as a security risk that is a 
different issue. However I would argue that given that for most users 
running 'sudo port XYZ' is a very common activity, they are quite likely 
to just enter their password without thinking much, so whether or not it 
is required is really a moot point...


So yeah, personally I consider allowing port to run through sudo without 
a password improves my security against me doing something bad with sudo 
later on, not degrades it.


Chris



R.
___
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: ~/.macports

[Chris Jones]

On 10/02/15 17:32, René J.V. Bertin wrote:

On Tuesday February 10 2015 17:10:37 Chris Jones wrote:


1) at least is solvable as you can configure your sudoers list to allow
your main user to run your port command (and that command only) through
sudoers without requiring a password.


I know that, but for some reason I've never managed to get that to work 
following just the instructions in the file. I'm sure I must have been doing 
something wrong, but in practice it was just as easy, for individual commands, 
to make a wrapper that prepends sudo.


works fine for me...

You are using visudo yes ? Then all you want is

chris   ALL=(ALL) NOPASSWD: /opt/local/bin/port

replacing chris with your username (and the path to port if it differs).


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

Re: ~/.macports

[Chris Jones]

On 10/02/15 15:06, René J.V. Bertin wrote:

On Tuesday February 10 2015 14:42:49 Jeremy Lavergne wrote:


Not sure you can make extended ACLs propagate the right way.


The old school option is creating a common group for both users and have
appropriate umasks.


Yep. That's subject to the same conditions I enumerated in my previous email. 
If group read or write permissions aren't set in a source archive (or by tclsh) 
it doesn't help much.

I do try to keep /opt/local in the admin group, with write access for group, 
though.



However, if you're the admin user sudo is already available.


I don't know about you, but I 1) don't like to have to type the same word everytime and 
2) don't want to become used to prefixing every command with sudo, because one day I'm 
going to edit a previous command to do something somewhere dangerous and wipe 
out stuff. It happens I do a `rm -rf ./*` in a MacPorts working directory. I'd hate to 
repeat that command when I happen to be (say) somewhere under /System and forget there's 
a sudo before it...


1) at least is solvable as you can configure your sudoers list to allow 
your main user to run your port command (and that command only) through 
sudoers without requiring a password.


2) is then no longer so much an issue, as the fact'sudo port' no longer 
requires a password means if you then happen to run 'sudo something 
else' without think, you will be prompted for it, which should cause 
you to think about what you are doing...


Doing what you are doing, running as your main user is just a bad idea 
all round IMHO... Do what you want, I'm sure you will, but its not 
recommended or supported for very good reasons..


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

Re: MacPorts forum(s)?

[Chris Jones]

Hi,

I for one so no particular reason why anyone would need a list of all 
list members, whatever password protection or mangling you put into 
place. If you want to send someone a mail and not sure if they are are 
member, just cc them as well and let the system sort the rest out.


I would be very much against such a list being made available to anyone 
who wants it (just having a password for the MP site is not enough, that 
is basically anyone who wants it.).


Chris

On 10/02/15 17:43, René J.V. Bertin wrote:

On Tuesday February 10 2015 12:30:07 Arno Hautala wrote:


Not by sending to the list, no. But there's always the option of sending to a 
hand-picked selection of list members, if there's a reason to limit the 
audience.


Also something that doesn't require having a public members list.


Not public, limited-access, only to members who have a password to access the 
list site. And in my mind, the hand-picking option comes in only after a query 
shows it to be preferable over sending to the list, of course.



I don't know if it's been discussed before, but a MacPorts forum would
seem like a valid topic to be spun off from this point.


Done. To kick off the discussion: has a MacPorts forum site ever been taken 
into consideration and if so, what were the reasons not to provide one (a 
summary would be fine)?

R.
___
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: using ninja instead of make

[Chris Jones]

Hi,

 On 1 Jan 2015, at 10:16 pm, René J.V. Bertin rjvber...@gmail.com wrote:
 
 On Thursday January 01 2015 22:38:32 Clemens Lang wrote:
 
 Hi
 
 The only configuration system (of relevant size and adoption) that falls 
 into this
 category is CMake. We could use ninja instead of make for all CMake ports, 
 but
 
 That's what I had in mind.
 
 orders of magnitude faster) than make when build times are largely dominated 
 by
 the compile times itself, rather than the execution time of the build tool.
 
 I must admit that I share your scepticism, but I've been seeing too many 
 comments to the contrary lately that I'm getting interested to try things out.

Ninja is possibly of interest to developers, who repeatedly (re)build packages 
during development, as ninja is a bit quicker at figuring out what needs 
rebuilding etc. For a single from scratch build there will be essentially no 
benefit, so do not expect replacing make with ninja to help much with a normal 
port build. 

 As you said, this would be in conjunction with CMake, which also happens to 
 generate Makefiles that are very verbose. That adds considerable overhead 
 (esp. with the long path names courtesy of MacPorts' build directory), which 
 could well exceed the time required for the actual destroot step.
 
 How would one set things up for this?
 
 Modify the CMake PortGroup to use ninja.
 
 Basically by adding  -G ninja to the configure.args, and then modify the 
 variables defining the make application and arguments? I'd do that first in a 
 test port rather than imposing it on every port depending on CMake.

I suspect that would be a bad idea, given most packages will not be tested 
against ninja. If done at all, it should be done on a port by port basis once 
that port has been properly tested. However, QI still very much doubt there is 
much to be gained for 'normal' port builds.

Chris

 
 R.
 ___
 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: Making QtCurve build on Snow Leopard

[Chris Jones]

On 30/11/14 19:05, Marko Käning wrote:

Hi,

in order to make port QtCurve install on Snow Leopard it is necessary to let
the port choose a macports-gcc compiler, preferrably the one perhaps already
installed on the system.


If you have to use a MacPorts compiler, you would be better off using a 
version of Clang, than gcc...





On Saturday November 29 2014 18:45:26 Marko Käning wrote:

just tried with the already installed gcc 4.7 using
  configure.compiler  macports-gcc-4.7
and it worked! :)



Some logic on how to use an existing or to be installed macports-gcc-4.* 
compiler
should be inserted into the portfile for SL, I suppose...


Could someone point me to a port which achieves something similar, so that
I could re-use the relevant code?

Greets,
Marko
___
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: Port deactivate boost hangs forever

[Chris Jones]

Hangs forever here. I interrupted it, tried to deactivate and de-install 
manually, to no avail.

What am I supposed to do at this point?


wait longer. It will take a while but will eventually finish...


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

Re: Port deactivate boost hangs forever

[Chris Jones]

On 10/11/14 09:42, Vincent Habchi wrote:

Hi Chris,


wait longer. It will take a while but will eventually finish…


Yep, it did. Thanks. But that’s really unexpected, especially since I run a MBA 
with those super-fast PCI-e SSD.
I think we ought even to warn the user about this (but I don’t think it’s 
possible).


Are you running OSX 10.10 ? If so its a new issue there, somethings like 
this are taking a lot longer than before. I guess idea is to fix it 
rather than live with it with warnings, once someone figures out what is 
wrong ...




Vincent



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

Re: How to reliably find the C++11 array header?

[Chris Jones]

On 31/10/14 09:45, Thibaut Paumard wrote:

Hi,

Building of Gyoto failed on Montain Lion:
https://build.macports.org/builders/buildports-mtln-x86_64/builds/18764

The error message is:
/bin/sh ../libtool  --tag=CXX   --mode=compile /usr/bin/clang++
-DHAVE_CONFIG_H -I. -I.. -I../include  -I../include
-I/opt/local/include/udunits2/  -I/opt/local/include
-DGYOTO_NO_DEPRECATED -D_THREAD_SAFE -pthread
-DGYOTO_PREFIX=\/opt/local\ -pipe -Os -arch x86_64 -stdlib=libstdc++
-std=gnu++11 -MT Photon.lo -MD -MP -MF .deps/Photon.Tpo -c -o Photon.lo
Photon.C
In file included from Worldline.C:20:
../include/GyotoWorldline.h:36:11: fatal error: 'array' file not found
# include array

I don't understand this as the array header is part of the C++11
standard and the above command lines includes -std=gnu++11.


That might be so, but the compilers in OSX 10.8 and earlier do not 
*fully* support C++11


In the ROOT6 port, which also requires C++11 support, we use compiler 
black/white lists to enforce the use of MacPorts clang 3.4 compiler on 
OSX 10.8 and older, for similar reasons.




How should I fix this? Depend on a specific compiler? Add a directory to
the include search path? Is array still in the tr1 nampespace and
directory on the default Montain Lion compiler?

One way out is to add a snippet such as:

platform darwin 12 {
  configure.args-append --disable-c++11
}

I would rather avoid that as that would remove significant features from
this Gyoto build.

Kind regards, Thibaut.
___
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: Clang: Mavericks v. the rest (was Re: buildbot failure in MacPorts on buildports-mavericks-x86_64)

[Chris Jones]

Hi,

The warning is correct. If s_decoded.name is a boolean then 
s_decoded.name = 12 is always true. OSX10.9 has a newer clang, which 
issues a warning in this case 
(-Wtautological-constant-out-of-range-compare), older OSes have older 
clang versions that do not. Finally -Werror turns it into an error.


So basically its a bug in the code which should be reported upstream to 
get fixed.


Chris

On 15/10/14 02:22, Craig Treleaven wrote:

At 2:39 PM -0700 10/14/14, nore...@macports.org wrote:

The Buildbot has detected a failed build on builder
buildports-mavericks-x86_64 while building MacPorts.
Full details are available at:
 http://build.macports.org/builders/buildports-mavericks-x86_64/builds/7702


Can some kind person (Jeremy?) help me understand why the version of
Clang on the Mavericks buildbot is falling over while the Lion and
MtnLion versions don't even spit a warning?

Mavericks Clang errors out with the following:

test_dr.c:49:3: error: comparison of constant 12 with expression of type
'bool' is always true [-Werror,-Wtautological-constant-out-of-range-compare]
   BOZO_end_boolean(b_multiple_frame_rate)
   ^~~
./test_dr.h:102:39: note: expanded from macro 'BOZO_end_boolean'
 } while(!i_err  (s_decoded.name = 12));  \
~~ ^  ~~
(Complete log from the Mavericks buildbot attached.)

If I understand correctly (always dicey given I'm not a C developer),
this is a unit test with (I guess) an awkward construct. The thing is,
Clang on MtnLion doesn't complain at all on the same code.

What would be the best way to get past this?

Thanks,

Craig


___
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

Commit for ROOT6 update

[Chris Jones]

Hi,

Could I ask a committer, or anyone who is interested, to take a look at

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

which is an update to the ROOT6 port.

There is one issue, which is upstream and moved to a new internal LLVM 
version, which I believe prevents building on OSX 10.6. I think this is 
hard to fix, so suspect we will just have to declare this port 
unavailable on this OS. Is this acceptable ?


cheers Chris

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

Re: Checking for C++ runtime link mis-matches ?

[Chris Jones]

Hi,

 On 24 Jun 2014, at 01:01 am, Ryan Schmidt ryandes...@macports.org wrote:
 
 
 On Jun 23, 2014, at 12:50 PM, Christopher Jones jon...@hep.phy.cam.ac.uk 
 wrote:
 
 Does MacPorts now check for linking c++ runtime mis-matches, i.e. when one 
 library using one runtime, libc++ say, links against another using an 
 incompatible runtime, libstdc++ ?
 
 Not that I know of. My understanding was that a compile error would occur, so 
 you wouldn't ever get to the point of having a compiled item which you could 
 check; compilation would fail before that happened

Correct, this is what happens. I was just hoping to find a way to catch it 
before this stage, which could be at the end of a long compilation. Ie. port A 
uses port B. Prior to building, port A could check what runtime port B used, 
and if that differs to the one its is *about* to be built with, issue a 
warning/error.  Both ports do not need to be built, only port B.

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

Re: Buildbot failure for new ROOT ports

[Chris Jones]

 On 9 May 2014, at 03:02 pm, Mojca Miklavec mo...@macports.org wrote:
 
 On Fri, May 9, 2014 at 2:29 PM, Jeremy Lavergne wrote:
 Could someone explain the reason for the failure in
 
 https://build.macports.org/builders/buildports-mavericks-x86_64/builds/3369
 
 error: forward declaration of class cannot have a nested name specifier
 class AIDA::IAxis; // from AIDA
 
 I think that Chris was asking about the failure in root6, not about
 the failure in iAIDA. The failure in root6 was probably just a random
 temporary problem (downloader figured out that download was too slow
 and gave up?). It seems that a new build solved the problem:
 
 https://build.macports.org/builders/buildports-mavericks-x86_64/builds/3375

Yes, thanks. I half suspected it was just some transient error on the build 
bot..

 
 The iAIDA issue needs to be addressed separately of course.
 
 Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: non standard install location and binary packages

[Chris Jones]

Hi,


 On 10 May 2014, at 08:59 am, Eric Le Lay ele...@macports.org wrote:
 
 Hello list,
 
 I'm running macports 2.3.0 beta2 on 10.6.8 and can't configure macports
 to use binary archives. 
 
 I've set buildfromsource=never in macports.conf
 and used the -b flag with no success: they are simply ignored.
 It has recompiled freetype after glib2 after...
 
 my variants.conf is empty
 
 I've installed macports in a separate partition (/MAC2/x11/opt/local).
 Is it what's preventing me from using binary archives ?

Yes. Binary archives only work when using the default prefix.

 This would make sense but then why is port not issuing any warning or
 better failing when I set it to never build from source?
 
 Also it ignores build dependencies: it had to install graphite2 as a
 dependency and did not install cmake before. So install failed because
 it could not find the cmake executable.
 
 Are you aware of this? Is it specific to the beta2? Shall I open a
 ticket?
 
 Cheers,
 ___
 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: wildcarding port select files to install ?

[Chris Jones]

No takers ;)

I would like to finalise a new port select port, and thus if there is no 
way to do this, would like to know so I can just bite the bullet and 
list all the files by hand.


cheers Chris

On 08/04/14 16:54, Chris Jones wrote:

Hi,

Is it possible to wildcard the files in a XYZ_select port, so that all
the files that match the wildcard are installed when a version is
selected ? In particular with

https://trac.macports.org/browser/users/mojca/ports/sysutils/root_select

we would like some way to just have root_select install everything that
gets installed in /opt/local/libexec/rootN/bin. The only examples I
have seen explicitly list all the files. If we have to list them all
then fine (and maybe this is required so the 'none' option knows what to
remove ?), I am just curious as to if there is a way or not.

cheers 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

Re: Building clang/cling 3.5 for ROOT on Lion

[Chris Jones]

On 08/04/14 01:48, Ryan Schmidt wrote:


On Apr 7, 2014, at 18:09, Christopher Jones wrote:


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


clang 3.4 and earlier should build fine on 10.7.


Indeed. They aren't quite the same thing though in the end, as on OSX 
10.8 and newer it supports c++11, whereas on 10.7 it doesn't, because of 
the underlying system support. So the same clang34 compiler now builds 
root6 fine on OSX10.9, but fails on 10.7.


My recollection of all the previous times c++11 has been discussed, can 
be summarised as there is no obvious way to support it cleanly on older 
OSX releases. So if an upstream package, as ROOT6 has, is actively only 
targetting c++11 supporting compilers, then effectively these ports 
cannot be used on older OSX releases now. Is that correct, or am I being 
overly pessimistic here ?


cheers Chris
___
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

[Chris Jones]

Indeed. They aren't quite the same thing though in the end, as on OSX 10.8 and 
newer it supports c++11, whereas on 10.7 it doesn't, because of the underlying 
system support. So the same clang34 compiler now builds root6 fine on OSX10.9, 
but fails on 10.7.

My recollection of all the previous times c++11 has been discussed, can be 
summarised as there is no obvious way to support it cleanly on older OSX 
releases. So if an upstream package, as ROOT6 has, is actively only targetting 
c++11 supporting compilers, then effectively these ports cannot be used on 
older OSX releases now. Is that correct, or am I being overly pessimistic here ?


Using latest gcc (currently gcc48) might be a way to support C++11 on OS X  
10.9, but otherwise, with clang, C++11 requires 10.9+.


Yes, I thought of that. But as I understanding it mixing libc++ and 
libstdc++ runtimes is an absolute no no when c++11 is involved, so the 
user would have to update their MacPorts settings to build *everything* 
with gcc(48) ?


Chris
___
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

[Chris Jones]

Hi,

On 08/04/14 10:14, Mojca Miklavec wrote:

On Tue, Apr 8, 2014 at 10:12 AM, Chris Jones wrote:



Indeed. They aren't quite the same thing though in the end, as on OSX
10.8 and newer it supports c++11, whereas on 10.7 it doesn't, because of the
underlying system support. So the same clang34 compiler now builds root6
fine on OSX10.9, but fails on 10.7.

My recollection of all the previous times c++11 has been discussed, can
be summarised as there is no obvious way to support it cleanly on older OSX
releases. So if an upstream package, as ROOT6 has, is actively only
targetting c++11 supporting compilers, then effectively these ports cannot
be used on older OSX releases now. Is that correct, or am I being overly
pessimistic here ?



Using latest gcc (currently gcc48) might be a way to support C++11 on OS X
 10.9, but otherwise, with clang, C++11 requires 10.9+.


Yes, I thought of that. But as I understanding it mixing libc++ and
libstdc++ runtimes is an absolute no no when c++11 is involved, so the user
would have to update their MacPorts settings to build *everything* with
gcc(48) ?


So would it work in theory if ROOT could be compiled without any
external dependencies (other than Cocoa)? And is compiling it without
external dependencies (and with some limited functionality) feasible
at all?


Not really within MacPorts. root in macports is designed to use various 
macports provided dependencies. Thats the benefit of using MacPorts...


First try installing MacPorts gcc48, then use it to build root6 
standalone, outside macports, without it finding any of Macports 
libraries (so move /local/local out the way for a while). If that works, 
you could try try building inside macports, but you will have to first 
mac sure to build *every* dependency root needs with gcc48 as well, 
instead of the normal default compiler.


Honestly, this to me sounds like a lot of effort. I personally would be 
more inclined to invest that amount of effort in updating my system to 
10.9. Ultimately, this is the only way to get a system that properly 
supports c++11...




I checked and it seems that it's depending on CoreFoundation which
depends on /usr/lib/libobjc.A.dylib, no libstdc++ (but OpenGL depends
on /usr/lib/libstdc++.6.dylib and that's probably needed).

Btw: what's the trick to make fortran-based libraries depend on
/usr/lib/libstdc++.6.dylib in the current port (rather than on
/opt/local/lib/libgcc/libgcc_s.1.dylib)?


Fortran libraries do not need a C++ runtime at all ... If a library that 
contains fortran symbols is linking against a c++ runtime, it must be 
because it also contains C++ symbols.


Chris



Mojca



___
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

[Chris Jones]

 You can actually use libc++ all the way back to 10.6 (with the libcxx
 port). The trick is that if you build root against libc++, then every
 library it uses via a C++ API must also be built against libc++, and
 likewise for every library that uses it via a C++ API.

Yes, but that doesn't help here, as the libc++ on 10.6 does not support 
c++11 fully. See below.



It sounds like root wants to use bundled copies of all its dependencies,
which while suboptimal for all the usual reasons, does at least solve
that side of the problem. I don't know if root exposes a C++ API for its
dependents, but if it does, they could also be made to use libc++.


Not really. ROOT will use external dependencies just fine.

Its just ROOT6 has moved to a new interpreter based on clang, 'cling', 
and to build this ROOT6 does internally build parts of a clang release, 
which currently is I believe based on clang 3.5. They have also decided 
to fully embrace c++11 (I good thing) but this means root6 now only 
supports compilers that fully support c++11. That can be libc++ or 
libstdc++ (ROOT6 builds fine with gcc 4.8 on linux), it just has to be 
fully c++11 compliant...


Chris



___
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

[Chris Jones]

On 08/04/14 11:26, Joshua Root wrote:

On 2014-4-8 20:02 , Chris Jones wrote:



You can actually use libc++ all the way back to 10.6 (with the libcxx
port). The trick is that if you build root against libc++, then every
library it uses via a C++ API must also be built against libc++, and
likewise for every library that uses it via a C++ API.


Yes, but that doesn't help here, as the libc++ on 10.6 does not support
c++11 fully.


Which parts doesn't it support? The description of the port specifically
says that it is targeting C++11.


I am only going on the reports I have seen from Mojca (I only have 
OSX10.9) but it appears std::move at least is not supported.


Chris



- Josh



___
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

[Chris Jones]

I didn't say that libc++ doesn't work – I didn't try that at all (I'm
not even sure I know how to do it; maybe I could create a new macports
installation with instructions posted by Jeremy a while ago). I just
said that using clang-3.4 doesn't help as that doesn't support all
c++11 features needed by cling.


by using clang34 I believe you are implicitly using libc++ anyway...

Chris
___
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

[Chris Jones]

PS: It's not an issue of me personally upgrading the OS. I'll do that
sooner or later. But it would be slightly suboptimal if the port only
worked on 10.9.


As a general point, I agree, only OSX10.9 has full c++11 support. 
However, upstream claim to be targeting 10.8 and 10.9, so I would hope 
it would work on OSX10.8 as well (to be tested sometime, by someone who 
has access to a 10.8 machine). Whilst not ideal, I think this is 
reasonable coverage (given root5 will remain available for all versions).


Chris

___
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

[Chris Jones]

On 08/04/14 13:35, Ryan Schmidt wrote:


On Apr 8, 2014, at 07:34, Chris Jones wrote:


PS: It's not an issue of me personally upgrading the OS. I'll do that
sooner or later. But it would be slightly suboptimal if the port only
worked on 10.9.


As a general point, I agree, only OSX10.9 has full c++11 support. However, 
upstream claim to be targeting 10.8 and 10.9, so I would hope it would work on 
OSX10.8 as well (to be tested sometime, by someone who has access to a 10.8 
machine). Whilst not ideal, I think this is reasonable coverage (given root5 
will remain available for all versions).


Well, libc++ (with full C++11 support) is included in 10.8, it’s just not the 
default. As long as root doesn’t use any other libraries, it should build fine 
with that, if you instruct it to. But then any other software that wants to use 
root would have to do that as well.


I see. Well, that might then cause problems as well :(

___
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

[Chris Jones]

On 08/04/14 13:41, Joshua Root wrote:

On 2014-4-8 22:35 , Ryan Schmidt wrote:


On Apr 8, 2014, at 07:34, Chris Jones wrote:


PS: It's not an issue of me personally upgrading the OS. I'll do that
sooner or later. But it would be slightly suboptimal if the port only
worked on 10.9.


As a general point, I agree, only OSX10.9 has full c++11 support. However, 
upstream claim to be targeting 10.8 and 10.9, so I would hope it would work on 
OSX10.8 as well (to be tested sometime, by someone who has access to a 10.8 
machine). Whilst not ideal, I think this is reasonable coverage (given root5 
will remain available for all versions).


Well, libc++ (with full C++11 support) is included in 10.8, it’s just not the 
default. As long as root doesn’t use any other libraries, it should build fine 
with that, if you instruct it to. But then any other software that wants to use 
root would have to do that as well.


Indeed, if you can get around the issues with using a non-default
runtime on 10.8, then that should transfer pretty easily to 10.7 and
10.6 as well.


Thats OK for a standalone build, but the whole point of having root in 
macports is to pick up various dependencies from Macports. This trick 
would then only work if the user built all of these dependencies against 
libc++ as well. SO unless MacPorts is planning on switch its 10.8 builds 
to by default use libc++, this doesn't help much with getting the port 
working on 10.8


Chris



- Josh



___
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

[Chris Jones]

On 08/04/14 13:52, Mojca Miklavec wrote:

On Tue, Apr 8, 2014 at 2:46 PM, Chris Jones wrote:


Thats OK for a standalone build, but the whole point of having root in
macports is to pick up various dependencies from Macports. This trick would
then only work if the user built all of these dependencies against libc++ as
well. SO unless MacPorts is planning on switch its 10.8 builds to by default
use libc++, this doesn't help much with getting the port working on 10.8


One option could be

 if 10.9 or later:
 use dependencies from MacPorts
 else:
 use just the built-in libraries without any advanced
functionality or external libraries

which is still better than having a nonfunctional port ... of course
only if that works at all.


Honestly, I think that is debatable. It would also make the port file a 
mess.


You would have to find a way to prevent root from automatically finding 
the libraries under /opt/local. I suspect if you just remove all the 
dependencies, it will still find then.


Honestly, I think you are flogging  a dead horse a bit here. Unless you 
can find a clean way to get it working within MacPorts, my vote is just 
to flag root6 as only working on 10.9 (or 10.8, depending on if it works 
there or not) and beyond.


Chris



Mojca



___
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

[Chris Jones]

I'll see if I can manage to build the whole ROOT 6 with -stdlib=libc++
(without referencing any other piece from MacPorts). But that probably
means that I shouldn't use OpenGL from the system, right?


Don't forget, you will also need to rebuild each and every port that 
root uses, that uses a c++ runtime against libc++ as well...


Chris

___
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

[Chris Jones]

SO unless MacPorts is planning on switch its 10.8 builds to by default use 
libc++, this doesn't help much with getting the port working on 10.8


At this time, we believe it is best to leave 10.8 and earlier on libstdc++, and 
use libc++ on 10.9 and later. There is a FAQ entry…


Yes of course. I wasn't suggesting the policy should be changed, just I 
think it would be the only way to properly support c++11 on OSX10.8, if 
it where ever decided that was important enough to do. Sorry if that 
wasn't clear..


Chris

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

wildcarding port select files to install ?

[Chris Jones]

Hi,

Is it possible to wildcard the files in a XYZ_select port, so that all 
the files that match the wildcard are installed when a version is 
selected ? In particular with


https://trac.macports.org/browser/users/mojca/ports/sysutils/root_select

we would like some way to just have root_select install everything that 
gets installed in /opt/local/libexec/rootN/bin. The only examples I 
have seen explicitly list all the files. If we have to list them all 
then fine (and maybe this is required so the 'none' option knows what to 
remove ?), I am just curious as to if there is a way or not.


cheers Chris

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

Root port update

[Chris Jones]

Hi,

Could i ask a commitor to take a look at

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

It updates root to a new version, that fixes compilation with the latest Xcode 
5.1 on OSX 10.9, so it would be useful to get it out quickly.

Cheers Chris


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

Re: buildbot and binary archives ...

[Chris Jones]

Hi,

The first thing you should check is if the license in the Port file 
allows for the binaries to be distributed ?


Chris

On 20/02/14 14:54, Peter Danecek wrote:


Hi all,

from a user report I realised that there is probably no binary archive 
available for Maverick of one port I am maintaining.

I am now, wondering if there is a way to obtain more information, e.g.
- Which binary archives exist and when these were produced?
- Are there problems with the build on the buildbot?
- Can I get the main.log of these builds?
- etc.

Note that I am maintainer, but have no commit rights. From what I understand 
these info might be available to committers.

Is there a way to access them as maintainer as well?

Thanks!
~petr



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



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

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

[Chris Jones]

Hi,



- The only C++ runtime that Apple provides on all systems since 10.5(?)
   is the one delivered with gcc 4.2.1. I really doubt that Apple
   will change that to a recent libc++


You are wrong on this point. Apple have been abandoning gcc in favour of 
clang/LLVM over the last few OSX releases, and finished this in 10.9 
which does *not* have a 'gcc' compiler at all. OSX also does have 
libc++. In fact, its the only C++ runtime in 10.9.


On OSX Macports explicitly links using the libc++ runtime, where as on 
older releases it


This is exactly why c++11 code is fine on OSX10.9, as the default 
compiler libc++ used there supports it, but not on older OSC releases. 
This is why the c++ issue and OSX versions are mixed up here.


Chris

___
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?

[Chris Jones]

On 04/12/13 11:48, Titus von Boxberg wrote:

Am 04.12.2013 11:00, schrieb Chris Jones:

Hi,

On OSX Macports explicitly links using the libc++ runtime, where as on
older releases it

This is exactly why c++11 code is fine on OSX10.9, as the default
compiler libc++ used there supports it, but not on older OSC releases.
This is why the c++ issue and OSX versions are mixed up here.

As said, this is where the mix up of the issues gets a bit incorrect.

libc++ is available since 10.7.
clang is available from Apple way before Xcode 5.

It's just that the libc++ of 10.9 and clang of Xcode 5
are the first versions by Apple that have had a chance
to use the clang/libc++ that has (or claims to have)
full C++11 support (actually, I don't know
if that's really the case since I don't have 10.9/Xcode 5).

When sticking to C++03 or at most the subset of C++11
that had already been implemented when 10.7.x shipped
(which most ports currently do, I think),
macports should work with libc++ on the three most recent
OSX versions.
(However, I didn't test that assumption, so I don't know
if that's really correct from 10.7 onwards.)


That though is not really a robust definition that can be used in 
practise I think. A compiler that only implements some parts of the 
C++11 standard, doesn't implement the standard. Just saying yeah, it 
might work, as long as upstream only happen to use the parts of the 
standard our compilers implement is fragile and not going to work for long.


If we are going to go the the effort of getting support for c++11 on 
systems 10.9, the aim should be *full* support, or sooner or later the 
same issue will come up again. Partial support just postpones the problem.


Chris
___
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?

[Chris Jones]

Hi,

On 04/12/13 12:01, Ryan Schmidt wrote:


On Dec 4, 2013, at 05:29, Clemens Lang wrote:


Obviously C++11 support is a problem we're going to face sooner or
later. It is a problem now and I don't think just avoiding C++11 on
older systems is going to cut it.


I’m not entirely opposed to that actually. There are already many ports that 
don’t work on older systems, for various reasons. Requiring C++11 may well be 
another valid reason for a port requiring a newer OS.

Mavericks is a free update, supports the same hardware as Mountain Lion, and is 
a better OS than Mountain Lion. We should continue fixing our ports to work on 
Mavericks and encourage users to upgrade.



I concur with that.

For me 10.9 is just better than both 10.8 and 10.7, and for those 
systems upgrading is I think a bit of a no brainer. Yes, there might be 
a few niggles that some users dislike, but if they are serious about 
wanting c++11 features, they should consider it a serious option. last 
time I checked 10.9 adoption had exceeded both 10.8 and 10.7.


10.6 is perhaps slightly different in that it is the last release to 
support PowerPC applications. Maybe some users have a need to stick with 
this because of that (but then, any application that *still* hasn't 
provided an intel version now, clearly is dead in the water. Personally, 
I would be looking heavily for alternatives at this stage).


10.5 is the last PowerPC OS. But then, I think this is old enough that 
support can be just 'take what you can get'.


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

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

[Chris Jones]

Hi,


you dropped the last text block from my mail where I said
that I think that macports shouldn't care much
about users using macports libraries for their own software.


I very much disagree here. MacPorts is *not* just about providing a 
bunch of applications for users to run, but also about providing a 
framework within which people can develop their own private 
applications. This has been something MacPorts has cared about and I 
very much hope it stays that way.


Note, this does not mean I don't agree that perhaps the best appropriate 
here is to declare c++11 unavailable in macports in anything less than 
OSX10.9. Both internally to MacPorts, for building ports, and externally 
to users. That might well be the best way to proceed


Chris

___
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?

[Chris Jones]

Hi,

 On 4 Dec 2013, at 09:14 pm, Ned Deily n...@acm.org wrote:
 
 In article 529f1c08.4000...@hep.phy.cam.ac.uk,
 Chris Jones jon...@hep.phy.cam.ac.uk 
 wrote:
 10.6 is perhaps slightly different in that it is the last release to 
 support PowerPC applications. Maybe some users have a need to stick with 
 this because of that (but then, any application that *still* hasn't 
 provided an intel version now, clearly is dead in the water. Personally, 
 I would be looking heavily for alternatives at this stage).
 
 FTR, 10.6 is also the last release to support 32-bit-only Intel Core Solo and 
 Core Duo based Macs.  So there are users with Intel Macs who cannot migrate 
 from Snow Leopard.

Fair point, but surely a small and ever reducing user base ... Low hanging 
fruit need to be pruned sometime ...

 
 -- 
 Ned Deily,
 n...@acm.org
 
 ___
 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: C++11 on Mountain Lion and lower?

[Chris Jones]

Hi,

 On 5 Dec 2013, at 12:22 am, Clemens Lang c...@macports.org wrote:
 
 On Wed, Dec 04, 2013 at 03:46:49PM +0100, Clemens Lang wrote:
 Of the system libraries in /usr/lib/system, only a single one exports
 C++ symbols (and that seems to be related to kernel extension stuff).
 I haven't checked for the libraries in /usr/lib, but I'll try to come
 up with a shell script to look for C++ APIs in those libraries
 tonight. dyld is implemented in C++, but I think it only exposes C
 APIs.
 
 I've done that and found only 4 libraries in /usr/lib export C++ APIs
 (tested on 10.9):
 
 - libcupsppdc.1.dylib (what is this anyway?)
 - libhunspell-1.2.0.0.0.dylib (present in MacPorts)
 - libicucore.A.dylib (present in MacPorts)
 - libmecab.1.0.0.dylib (only a few symbols, what is this?)
 
 So in conclusion using a C++ runtime different from the one the host
 system uses might be a doable solution because these are the only
 libraries users would have to avoid.
 
 So remaining questions:
 - Which C++ runtime should be used? Host libc++? A newer libc++ from
   MacPorts? How can clang be convinced to use that?
 - Do we have the manpower to pull this off and support it?

I guess a version of libc++ from MacPorts would have the advantage it would 
allow the use of a complete c++11 implementation on systems where the host 
version is lacking. Could this be done by just making one of macports own clang 
compilers the default compiler... ? 

 
 To be honest, I think the last question needs to be answered with no
 and might kill the whole idea. At least we have some data on how
 dangerous it is to use trunk and change cxx_stdlib to libc++.
 
 -- 
 Clemens Lang
 
 ___
 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: C++11 on Mountain Lion and lower?

[Chris Jones]

Hi,

I am not an expert, but based on the discussion in

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

my understanding is there is no easy way to enable c++11 on systems 
older than 10.9 using the current MacPorts release. You need to use the 
libc++ runtime by default everywhere, not, libstdc++, and this is only 
the case on Mavericks.


MacPorts base in the trunk has the option to force the use of libc++ 
instead of libstdc++. See comment 19 in the above. This though requires 
the user to, use trunk, manually edit macports.conf then rebuild all 
their ports. I don't know if its the plan to ever do this by default on 
OSX10.8 or older...


Chris

In 03/12/13 14:09, Clemens Lang wrote:

Hi,

does anybody know how I can compile C++11 code on Mountain Lion and
lower without using libc++?

The problem I face is that rethinkdb uses std::move (and probably other
features) from C++11. To do this, it checks for the clang compiler and
passes -stdlib=libc++ in CXXFLAGS if it detects clang on OS X.

Rethinkdb also uses protobuf-cpp, which requires linking against
libprotobuf.dylib. However, libprotobuf is built against libstdc++. This
leads to the following problem when rethinkdb tries to use protobuf:


Error: Unable to compile sample protobuf file. Try running ./configure with the 
--fetch protoc option
Undefined symbols for architecture x86_64:
   google::protobuf::MessageFactory::InternalRegisterGeneratedFile(char const*, void 
(*)(std::__1::basic_stringchar, std::__1::char_traitschar, std::__1::allocatorchar  
const)), referenced from:
   protobuf_AddDesc_mk_2fgen_2fprotoc_2ftest_2eproto() in test-umpU92.o
   google::protobuf::DescriptorPool::FindFileByName(std::__1::basic_stringchar, 
std::__1::char_traitschar, std::__1::allocatorchar  const) const, referenced 
from:
   protobuf_AssignDesc_mk_2fgen_2fprotoc_2ftest_2eproto() in test-umpU92.o


So the problem is that the linker is looking for the symbol in
libprotobuf that was compiled against libc++ (see the usage of
std::__1::basic_string, which is specific to libc++), but cannot find
the symbol, because libprotobuf has been compiled against libstdc++.

Any ideas how to fix this? Should I just pass --fetch protoc --static
protoc to have rethinkdb compile a local version of protobuf?



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

ROOT update to work around FreeType issue

[Chris Jones]

Hi,

Could someone with commit access take a look at.

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

?

It adds a work around for an issue ROOT has with the recent FreeType 
2.5.1 update. Not yet really clear where the issue lies, but my bet is 
with ROOT itself, so this work around (which is to revert to ROOT using 
its own internal FreeType build) will be needed I think with the current 
5.34.12 release.


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

Re: Detect OS upgrades and refer users to Migration

[Chris Jones]

 On 17 Nov 2013, at 06:06 pm, Landon Fuller land...@macports.org wrote:
 
 
 On Nov 4, 2013, at 20:06 , Ryan Schmidt ryandes...@macports.org wrote:
 
 ... we’d really prefer them to uninstall and reinstall all ports.
 
 Users *really* (and rightfully) hate this, especially when there aren't 
 binary packages available. For our local machines, we simply upgraded 
 MacPorts base, and left the existing port installs in place -- so far, 
 everything has worked fine.
 
 In theory, Apple should provide ABI compatibility across releases; is there 
 any modern reason why we should still be encouraging (or enforcing) a full 
 uninstall and reinstall?

Yes, there are. For instance the change in the default c++ runtime from 
libstdc++ to libc++ with OSX 10.9. These two runtimes cannot reliably be mixed, 
so rebuilding all ports is the only safe option. Yes, you might get by not 
doing this, for a while, but sooner or later you will run into problems, and 
the root cause is often hard to spot. users might consider the rebuild a pain, 
but the macPorts devs equally would consider the stream of 'bug' reports 
because this is not done, a pain... A rebuild is better all round, in the long 
term.

 
 -landonf
 ___
 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: Detect OS upgrades and refer users to Migration

[Chris Jones]

 On 17 Nov 2013, at 07:22 pm, Landon Fuller land...@macports.org wrote:
 
 
 On Nov 17, 2013, at 14:02 , Chris Jones jon...@hep.phy.cam.ac.uk wrote:
 
 Yes, there are. For instance the change in the default c++ runtime from 
 libstdc++ to libc++ with OSX 10.9. These two runtimes cannot reliably be 
 mixed, so rebuilding all ports is the only safe option. Yes, you might get 
 by not doing this, for a while, but sooner or later you will run into 
 problems, and the root cause is often hard to spot. users might consider the 
 rebuild a pain, but the macPorts devs equally would consider the stream of 
 'bug' reports because this is not done, a pain... A rebuild is better all 
 round, in the long term.
 
 Given that macports::revupgrade_scanandrebuild is already scanning for broken 
 dylib dependencies, I think marking C++ runtime mismatches within the 
 scanning dependency graph would be well within its purview?

Possibly, but then i doubt it would spot all such problems (i know for instance 
it wouldn't spot all problems with root, as there not all libraries are loaded 
via 'traditional' linker dependencies, but instead via introspection etc. ) 
plus, i am sure others could come up with other issues, not just the c++ 
runtime. 

I suppose theoretically macports could perhaps be patched to deal with them 
all,  but thats a lot of work for someone, and to be honest for me its not 
clear its worth it. Until such a time, telling users to follow the migration 
instructions is the best approach.

Chris

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

Re: port update (ROOT - Support for OSX10.9)

[Chris Jones]

Hi,

Sorry to pester, but i would be grateful if a commiter could take a look at the 
two tickets below.

Cheers chris


 On 1 Nov 2013, at 09:59 pm, Chris Jones jon...@hep.phy.cam.ac.uk wrote:
 
 Hi,
 
 p.s.
 
 Could a commuter also take a look at.
 
 https://trac.macports.org/ticket/40949
 
 its needed to fix the pythia variant of ROOT.
 
 cheers Chris
 
 On 1 Nov 2013, at 5:12pm, Chris Jones jon...@hep.phy.cam.ac.uk wrote:
 
 Hi,
 
 Could I ask a committer to take a look at
 
 https://trac.macports.org/ticket/41108
 
 I know it hasn't been submitted for that long…. But it fixes build problems 
 the current port has with OSX 10.9, so it would be good to get it committed 
 asap. Thanks in advance.
 
 cheers 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
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

port update (ROOT - Support for OSX10.9)

[Chris Jones]

Hi,

Could I ask a committer to take a look at

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

I know it hasn't been submitted for that long…. But it fixes build problems the 
current port has with OSX 10.9, so it would be good to get it committed asap. 
Thanks in advance.

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: port update (ROOT - Support for OSX10.9)

[Chris Jones]

Hi,

p.s.

Could a commuter also take a look at.

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

its needed to fix the pythia variant of ROOT.

cheers Chris

On 1 Nov 2013, at 5:12pm, Chris Jones jon...@hep.phy.cam.ac.uk wrote:

 Hi,
 
 Could I ask a committer to take a look at
 
 https://trac.macports.org/ticket/41108
 
 I know it hasn't been submitted for that long…. But it fixes build problems 
 the current port has with OSX 10.9, so it would be good to get it committed 
 asap. Thanks in advance.
 
 cheers 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: Recommended permissions and ownership of Subversion checkout of dports

[Chris Jones]

I am aware (and so should you be), that these files are editable by my
user account and contain code that will be run with super user
privileges – so if you're concerned about possible privilege
escalations, you should create the checkout as root (which also implies
you need root privileges to edit the Portfiles).


What I'm concerned with is not having to type my password dozens of times a 
day. This has become increasingly difficult ever since the gsoc08-privileges 
branch was merged in and basically made non-root MacPorts installations 
unusable.

I tried your suggestion. sudo chown -R rschmidt:macports .  sudo chmod -R 770 . in my 
dports directory. Then I ran sudo port sync which succeeded and pulled in a few updates. Then I 
checked permissions in the directory. Files updated by the sync do not have these permissions. For example, 
the gegl and glfw Portfiles have 644 permissions instead of 770, so only the macports user can write to 
them, so trying to edit them in my editor results in the administrator password prompt that I'm trying to 
avoid.



why not just update your sudoers permissions file, to allow your main 
account to run the port command as root, without requiring a password 
(or just give it a longer timeout, which would be my preferred way) ? 
Seems easier than faffing with file permissions ..


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

Re: CMake warning wrt frameworks during configure phase on Snow Leopard

[Chris Jones]

Hi,

 
 The suggested fix in http://bugs.python.org/issue14018 is to manually fix 
 the symlinks in /Developer/SDKs/MacOSX10.6.sdk … !
 
 Hmmm… I don't know what and how to fix this.

Any guide that is telling you to manually start fiddling with sym links in 
system areas, is a guide you should stay away from.

Just a thought, but maybe updating to an Xcode 4 release, there is one for OSX 
10.6, would fix things … Any reason to stay on Xcode 3 ?

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: Fortran recipe

[Chris Jones]

Hi,

I've submitted an update to ROOT to try and address the C++ runtime issues (as 
well as bump the version to the latest upstream version, and improve the cocoa 
variant). 

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

Could someone take a look ?

cheers Chris

On 26 Aug 2013, at 2:07am, Jeremy Huddleston Sequoia jerem...@macports.org 
wrote:

 
 On Aug 25, 2013, at 13:53, Chris Jones jon...@hep.phy.cam.ac.uk wrote:
 
 Hi,
 
 On 25 Aug 2013, at 7:22pm, Christoph Deil deil.christ...@gmail.com wrote:
 
 
 On Aug 25, 2013, at 10:44 AM, Mojca Miklavec mo...@macports.org wrote:
 
 On Sun, Aug 25, 2013 at 5:16 PM, Jeremy Huddleston Sequoia wrote:
 Seeing as how many developers don't understand the problems surrounding 
 mixing multiple versions of the C++ runtime in a single process, I doubt 
 that users understand those problems.  I think the root port needs to be 
 simplified significantly.
 
 Does root use any C++ APIs exposed by the host or other ports?  Does root 
 expose any C++ APIs?
 
 I don't understand much about those problems either.
 
 I also don't understand the issues, or how to debug / check them.
 
 I am using a non-public gamma-ray astronomy data analysis package built on 
 top of ROOT.
 After a lot of trial and error I did get it to compile with Macports gcc, I 
 never managed to compile it with Apple gcc or (Apple or Macports) clang.
 So at least I can write code and check that it compiles on my Mac  … 
 actually running the software sometimes works and sometimes mysteriously 
 crashes.
 
 Probably this is a very specialised use case, if the Macports GCC variants 
 are removed from the ROOT port I'll just build ROOT from source myself, no 
 problem if that is the right thing to do to avoid C++ runtime mix errors 
 (whatever that means).
 
 The issue is in essence the gcc compilers use one c++ runtime library 
 (libstdc++), the other compiles, clang etc. use another (libc++). 
 
 That's not exactly correct.  There are three runtimes we are concerned with: 
 host libstdc++, host libc++, and MacPorts libstdc++ (libgcc port)
 
 Here's the breakdown:
 
 gcc-*: host libstdc++
 *llvm-gcc-4.2: host libstdc++
 apple-gcc-*  : host libstdc++
 macports-gcc-*   : MP libstdc++
 dragonegg-*  : MP libstdc++
 clang  163  : host libstdc++
 clang = 163 : host libstdc++ or host libc++
 macports-clang-* : host libstdc++ or host libc++
 
 Mixing these is a bad idea, so if you where to compile root using gcc, you 
 should in theory compile *all* ports that that uses with it as well. This is 
 not done. Maybe the crashes you refer to are to do with this …
 
 Removing the gcc variants is thus a good idea to avoid this. I have a 
 version under test which does this, uses the fortran recipe JH posted 
 earlier in this thread, and fixes the cocoa variant by selecting the 
 compiler in a better way. 
 
 This solves the primary issue of mixing the MP runtime and the host runtime.  
 We will still need to deal with host libc++ vs host libstdc++, but those 
 problems are much more obvious (build failure).
 
 Note that for those users that *really* want to use gcc, they will always be 
 able to do something like
 
 sudo port install root configure.compiler=macports-gcc-4.8
 
 So all is not lost, but by doing so you are accepting whatever the 
 consequences might be.
 
 And such expert users might want to set configure.compiler globally after 
 they first bootstrap it.
 
 --Jeremy
 



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

Re: Fortran recipe

[Chris Jones]

Hi,

For the science/root port, the reason the port provides variants to use various 
gcc (and clang) compilers is not really because of fortran. ROOT provides an 
interactive build environment, and that environment is based on the compiler 
used to build ROOT. As such the user might have a reason to want a particular 
compiler, so the port provides various options to allow this. So for this port, 
I don't think changing anything makes sense.

cheers Chris

On 25 Aug 2013, at 3:20am, Jeremy Huddleston Sequoia jerem...@macports.org 
wrote:

 ping.  Can I please get some feedback on this?  Can some maintainers of 
 fortran ports in math/science categories give this a try?  We really need to 
 get ports weened off of g++-mp-4.X ...
 
 Thanks,
 Jeremy
 
 On Aug 19, 2013, at 15:05, Jeremy Huddleston Sequoia jerem...@macports.org 
 wrote:
 
 Most ports that require fortran set configure.compiler to macports-gcc-4.X.  
 This gets the port a fortran compiler, but it also switches the C and C++ 
 compilers as well.  If the port also has C and C++ sources, then it would be 
 preferable to leave configure.cc and configure.cxx alone and just choose a 
 fortran compiler.
 
 I'm suggesting that such ports be updated to do this and want some feedback 
 on this Portfile recipe:
 
 set gcc_versions {4.3 4.4 4.5 4.6 4.7 4.8 4.9}
 set default_fortran_variant +gcc48
 
 foreach ver ${gcc_versions} {
   set ver_no_dot [join [split ${ver} .] ]
   variant gcc${ver_no_dot} description {build with gfortran from 
 gcc${ver_no_dot}} conflicts g95 {
   depends_lib-append port:libgcc
   depends_build-append port:gcc${ver_no_dot}
 
   configure.fc  ${prefix}/bin/gfortran-mp-${ver}
   configure.f77 ${prefix}/bin/gfortran-mp-${ver}
   configure.f90 ${prefix}/bin/gfortran-mp-${ver}
   }
 
   foreach over ${gcc_versions} {
   if {${ver} == ${over}} {
   continue
   }
 
   set over_no_dot [join [split ${over} .] ]
   variant gcc${ver_no_dot} conflicts gcc${over_no_dot} {}
   }
 
   variant g95 conflicts gcc${ver_no_dot} {}
 
   if {[variant_isset gcc${ver_no_dot}]} {
   set default_fortran_variant 
   }
 }
 
 variant g95 description {build with g95} {
   depends_build-append port:g95
   configure.fc ${prefix}/bin/g95
   configure.f77 ${prefix}/bin/g95
   configure.f90 ${prefix}/bin/g95
 }
 
 if {[variant_isset g95]} {
   set default_fortran_variant 
 }
 
 if {${default_fortran_variant} != } {
   default_variants ${default_fortran_variant}
 }
 
 
 ___
 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: Fortran recipe

[Chris Jones]

Hi,

On 25 Aug 2013, at 6:44pm, Mojca Miklavec mo...@macports.org wrote:

 On Sun, Aug 25, 2013 at 5:16 PM, Jeremy Huddleston Sequoia wrote:
 Seeing as how many developers don't understand the problems surrounding 
 mixing multiple versions of the C++ runtime in a single process, I doubt 
 that users understand those problems.  I think the root port needs to be 
 simplified significantly.
 
 Does root use any C++ APIs exposed by the host or other ports?  Does root 
 expose any C++ APIs?
 
 I don't understand much about those problems either.
 
 Root probably doesn't just expose APIs, but actually provides C++
 interpreter and compiler of some sort, CINT and CLING. (I'm sorry that
 I cannot explain it better, but I don't really understand how it all
 works. Maybe http://root.cern.ch/drupal/category/package-context/cling
 answers any of your questions?)

I suspect to avoid the issues with the C++ runtime we need to remove the gcc 
variants, as Jeremy suggests. 
This might cause some users problems, who have been using these compilers 
seemingly without tripping over the c++ runtime issues, but as this is more by 
luck than anything else, I guess we just need to do it. At least ROOT now 
compiles with the system compilers with all supported platforms (by which I 
mean the buildbots, 10.6 to 10.8). This hasn't always been the case and the gcc 
variants where partly there as a solution to that. 

Its not clear to me if we also need to remove the variants that build with 
Macports clang. As I understand things these aren't affected by the c++ runtime 
issues ? These variants are still useful, for instance if the users wants to 
use the cocoa graphical backend, as these only works when built with clang, so 
on systems that don't use this as a default compiler, its convenient to have 
the clang variants as a fall back.

ROOT has very very little fortran in it, so personally I would be happy to just 
disable it completely. If people think it is still needed, then I can look to 
using Jeremy's recipe.

 
 Root has a few more problems. Last time when I tried compiling Root 6,
 it failed to work with Fortran
 (https://sft.its.cern.ch/jira/browse/ROOT-4874), I wasn't able to
 disable Fortran at all (it was possible to disable it with
 ./configure, but not with CMake). On top of that problem came the
 inability to prevent shipping -arch flags to Fortran compilers:
 https://trac.macports.org/ticket/37732 (this problem affects at least
 Root if it ever gets ported to CMake-based installation and plplot).

Lets not confuse things. ROOT6 and and cake are different issues ;)

 
 Mojca



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: Fortran recipe

[Chris Jones]

Hi,

On 25 Aug 2013, at 07:29 PM, Ryan Schmidt ryandes...@macports.org wrote:

 
 On Aug 25, 2013, at 12:56, Chris Jones wrote:
 
 Its not clear to me if we also need to remove the variants that build with 
 Macports clang. As I understand things these aren't affected by the c++ 
 runtime issues ? These variants are still useful, for instance if the users 
 wants to use the cocoa graphical backend, as these only works when built 
 with clang, so on systems that don't use this as a default compiler, its 
 convenient to have the clang variants as a fall back.
 
 Are there any drawbacks to using clang? If not, maybe you should blacklist 
 those compilers that won't build the cocoa backend. That way the cocoa 
 backend will always be available.

It won't help, as i think only on OSX 10.8 is there a system clang compiler 
that works with the cocoa backend. On older OS X versions i suspect macports 
clang is the only option, and i don't want to make that the default compiler on 
these systems, just for this one option, that isn't that commonly used anyway.

Cheers Chris

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

Re: Fortran recipe

[Chris Jones]

Hi,

On 25 Aug 2013, at 07:50 PM, Jeremy Huddleston Sequoia jerem...@macports.org 
wrote:

 
 On Aug 25, 2013, at 11:29, Ryan Schmidt ryandes...@macports.org wrote:
 
 
 On Aug 25, 2013, at 12:56, Chris Jones wrote:
 
 Its not clear to me if we also need to remove the variants that build with 
 Macports clang. As I understand things these aren't affected by the c++ 
 runtime issues ? These variants are still useful, for instance if the users 
 wants to use the cocoa graphical backend, as these only works when built 
 with clang, so on systems that don't use this as a default compiler, its 
 convenient to have the clang variants as a fall back.
 
 Are there any drawbacks to using clang? If not, maybe you should blacklist 
 those compilers that won't build the cocoa backend. That way the cocoa 
 backend will always be available.
 
 I suggest that your +cocoa variants use compiler.whitelist 
 macports-clang-3.2 macports-clang-3.1 to force one of those compilers.  Can 
 you explain why 3.3 and Apple clang don't work?

They do work, at least on OSX 10.8. I cannot test myself anything older, but i 
suspect there might be problems with the apple clang versions in older OSes. 

 
 For Fortran, you should just set compiler.fc, etc.  This will ensure that you 
 have a fortran compiler and are using a C++ compiler that uses the expected 
 C++ runtime.

Indeed, thats what we will do.

Chris

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

Re: Fortran recipe

[Chris Jones]

On 25 Aug 2013, at 8:04pm, Jeremy Huddleston Sequoia jerem...@macports.org 
wrote:

 
 On Aug 25, 2013, at 11:54, Chris Jones jon...@hep.phy.cam.ac.uk wrote:
 
 I suggest that your +cocoa variants use compiler.whitelist 
 macports-clang-3.2 macports-clang-3.1 to force one of those compilers.  
 Can you explain why 3.3 and Apple clang don't work?
 
 They do work, at least on OSX 10.8. I cannot test myself anything older, but 
 i suspect there might be problems with the apple clang versions in older 
 OSes. 
 
 Ok, then blacklisting is the right option instead of the whitelist that I 
 sent you.  Use the blacklist versions port group and blacklist maybe {clang  
 300}, {clang  421}, or {clang  425} depending on what works.  You should 
 append 3.2 and 3.1 to fallbacks since 3.3 will be in the blacklist (I'm still 
 curious why that is).

So now I have

 PortGroup compiler_blacklist_versions 1.0
 # Force a compatible clang compiler
 compiler.blacklist-append {clang  425}
 compiler.fallback-append macports-clang-3.2 macports-clang-3.1

To make this work though, I also need to black list any compiler that isn't 
clang, so on systems where the default system compiler isn't clang, it will 
fallback to the macports-clang, no ? whats the string to add to the blacklist 
list for this ?

cheers Chris

 --Jeremy
 



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

Re: Fortran recipe

[Chris Jones]

On 25 Aug 2013, at 8:14pm, Ryan Schmidt ryandes...@macports.org wrote:

 
 On Aug 25, 2013, at 13:51, Chris Jones  wrote:
 
 On 25 Aug 2013, at 07:29 PM, Ryan Schmidt wrote:
 
 On Aug 25, 2013, at 12:56, Chris Jones wrote:
 
 Its not clear to me if we also need to remove the variants that build with 
 Macports clang. As I understand things these aren't affected by the c++ 
 runtime issues ? These variants are still useful, for instance if the 
 users wants to use the cocoa graphical backend, as these only works when 
 built with clang, so on systems that don't use this as a default compiler, 
 its convenient to have the clang variants as a fall back.
 
 Are there any drawbacks to using clang? If not, maybe you should blacklist 
 those compilers that won't build the cocoa backend. That way the cocoa 
 backend will always be available.
 
 It won't help, as i think only on OSX 10.8 is there a system clang compiler 
 that works with the cocoa backend.
 
 Why won't it help? We have the compiler_blacklist_versions portgroup you can 
 use to blacklist specific versions of Xcode clang.

yes I guess so, I'm starting to look i to this (I hadn't thought of using 
white/black lists so far)…

 
 On older OS X versions i suspect macports clang is the only option, and i 
 don't want to make that the default compiler on these systems, just for this 
 one option, that isn't that commonly used anyway.
 
 We're already forcing MacPorts clang on older systems on other ports. It's 
 going to become more common, I think.
 
 
 On Aug 25, 2013, at 13:54, Jeremy Huddleston Sequoia wrote:
 
 SL is quite dated at this point...
 
 And yet it is the version of OS X that many Mac users still prefer to run. Up 
 to Snow Leopard, every release of OS X was decidedly superior to the previous 
 one, and users enjoyed upgrading to it. As of Lion, many users were unhappy 
 with the changes Apple made in the OS and chose not to upgrade.
 
 http://www.patentlyapple.com/patently-apple/2013/04/snow-leopard-remains-the-most-popular-version-of-os-x.html
 
 I did not upgrade to Lion until new hardware forced me to. My father shows no 
 signs of wanting to upgrade his iMac beyond Snow Leopard. A friend of mine 
 suffered with Mountain Lion on his Mac mini for several months before 
 downgrading back to Snow Leopard with great relief. Hopefully Mavericks will 
 right the wrongs of the past two releases and get more users to upgrade…



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: Fortran recipe

[Chris Jones]

On 25 Aug 2013, at 8:17pm, Ryan Schmidt ryandes...@macports.org wrote:

 
 On Aug 25, 2013, at 14:15, Chris Jones wrote:
 
 So now I have
 
   PortGroup compiler_blacklist_versions 1.0
   # Force a compatible clang compiler
   compiler.blacklist-append {clang  425}
   compiler.fallback-append macports-clang-3.2 macports-clang-3.1
 
 To make this work though, I also need to black list any compiler that isn't 
 clang, so on systems where the default system compiler isn't clang, it will 
 fallback to the macports-clang, no ? whats the string to add to the 
 blacklist list for this ?
 
 compiler.blacklist-append apple-gcc-4.0 apple-gcc-4.2 gcc-3.3 gcc-4.0 gcc-4.2 
 llvm-gcc-4.2 macports-gcc-4.2 macports-gcc-4.3 macports-gcc-4.4 
 macports-gcc-4.5 macports-gcc-4.6 macports-gcc-4.7 macports-gcc-4.8 
 macports-gcc-4.9 macports-llvm-gcc-4.2
 

Ah thanks. I was hoping there was a way to wild card that somehow ( so to match 
say *gcc*) to avoid a long list like that ?

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: Fortran recipe

[Chris Jones]

Hi,

On 25 Aug 2013, at 8:09pm, Mojca Miklavec mo...@macports.org wrote:

 On Sun, Aug 25, 2013 at 8:54 PM, Chris Jones wrote:
 On 25 Aug 2013, at 07:50 PM, Jeremy Huddleston Sequoia wrote:
 
 I suggest that your +cocoa variants use compiler.whitelist 
 macports-clang-3.2 macports-clang-3.1 to force one of those compilers.  
 Can you explain why 3.3 and Apple clang don't work?
 
 They do work, at least on OSX 10.8. I cannot test myself anything older, but 
 i suspect there might be problems with the apple clang versions in older 
 OSes.
 
 If that's the cocoa that just doesn't use X11 but still looks ugly
 like this one here
http://root.cern.ch/root/html/TBrowser.html#TBrowser:description

 (http://indico.cern.ch/getFile.py/access?contribId=11resId=0materialId=slidesconfId=217511)
 then I can confirm that it also works on Lion (and I believe that the
 option should be on by default, at least on systems that are recent
 enough to use it).

Yes, thats the one. I disagree its ready to be the default though. It has too 
many issues (like it doesn't work with python, unlike the X11 backend. I 
personally rely on this). Maybe at some point in the future it could be 
considered...

Chris

 
 I'm using Xcode 4.6.3 (I think I upgraded mainly because I wanted to
 be able to use TextMate).
 
 Mojca



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: Fortran recipe

[Chris Jones]

Thanks, it wasn't clear to me something as simply as that was going to work !

On 25 Aug 2013, at 8:24pm, Lawrence Velázquez lar...@macports.org wrote:

 On Aug 25, 2013, at 3:17 PM, Ryan Schmidt ryandes...@macports.org wrote:
 
 On Aug 25, 2013, at 14:15, Chris Jones wrote:
 
 So now I have
 
  PortGroup compiler_blacklist_versions 1.0
  # Force a compatible clang compiler
  compiler.blacklist-append {clang  425}
  compiler.fallback-append macports-clang-3.2 macports-clang-3.1
 
 To make this work though, I also need to black list any compiler that isn't 
 clang, so on systems where the default system compiler isn't clang, it will 
 fallback to the macports-clang, no ? whats the string to add to the 
 blacklist list for this ?
 
 compiler.blacklist-append apple-gcc-4.0 apple-gcc-4.2 gcc-3.3 gcc-4.0 
 gcc-4.2 llvm-gcc-4.2 macports-gcc-4.2 macports-gcc-4.3 macports-gcc-4.4 
 macports-gcc-4.5 macports-gcc-4.6 macports-gcc-4.7 macports-gcc-4.8 
 macports-gcc-4.9 macports-llvm-gcc-4.2
 
 This should also work:
 
compiler.blacklist-append   *gcc*
 
 vq



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: Fortran recipe

[Chris Jones]

Hi,

 There is.
 
 http://trac.macports.org/changeset/104174

Is this in the latest release, or only available in the trunk for the moment ?

 
 vq



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