Re: Updating tk +quartz failed on Snow Leopard

[Ken Cunningham]

On 2016-08-25, at 8:20 PM, Kevin Walzer wrote:

> On 8/25/16 10:02 PM, Ryan Schmidt wrote:
>> I just haven't researched whether one is supposed to use 
>> MAC_OS_X_VERSION_MIN_REQUIRED or MAC_OS_X_VERSION_MAX_ALLOWED or 
>> __MAC_OS_X_VERSION_MAX_ALLOWED or something else.
> Can someone try something like this:
> 
> #if MAC_OS_X_VERSION_MIN_REQUIRED < 1070
> 
> [do someStuff:here andHere];
> 
> #endif
> 
> and see if it builds on 10.6? If so, send me a patch and I'll test it on 
> 10.11 and commit if it works. I have no access to 10.6.
> 
> Thanks,
> Kevin
> 
> -- 
> Kevin Walzer
> Code by Kevin/Mobile Code by Kevin
> http://www.codebykevin.com
> http://www.wtmobilesoftware.com
> 
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev


It looks like it works as expected. There are different ways to do the same 
thing, but the easy-to-read, non-underscore version of these tests uses 
 rather than the newer but more complicated 
, and worked like this:

Testing out the following code on snow leopard:

--
#include 
#include 

#define MY_CURRENT_OS   MAC_OS_X_VERSION_MAX_ALLOWED

int main() {

printf("%d\n", MAC_OS_X_VERSION_MAX_ALLOWED); 
printf("%d\n", MAC_OS_X_VERSION_MIN_REQUIRED);



#if MAC_OS_X_VERSION_MAX_ALLOWED >= 1070
printf("This code will only be seen and compiled Lion or greater!\n");
// and more
#endif

#if MAC_OS_X_VERSION_MAX_ALLOWED == 1060
printf("This code is only seen and compiled on Snow Leopard\n");
// and more
#endif

#if MAC_OS_X_VERSION_MAX_ALLOWED <= 1050
printf("This code is only seen and compiled on Leopard or Older\n");
// and more

#endif


#if MAC_OS_X_VERSION_MIN_REQUIRED < 1070
printf("This MIN version specifies code that is only seen and compiled 
on Snow Leopard or earlier\n");
// and more
#endif


return 0;
}

--

produces the following output:

KensMacBookPro:compiler tests cunningh$ clang test.c -o test
KensMacBookPro:compiler tests cunningh$ ./test
1060
1060
This code is only seen and compiled on Snow Leopard
This MIN version specifies code that is only seen and compiled on Snow Leopard 
or earlier

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

Re: Updating tk +quartz failed on Snow Leopard

[Kevin Walzer]

On 8/25/16 10:02 PM, Ryan Schmidt wrote:

I just haven't researched whether one is supposed to use 
MAC_OS_X_VERSION_MIN_REQUIRED or MAC_OS_X_VERSION_MAX_ALLOWED or 
__MAC_OS_X_VERSION_MAX_ALLOWED or something else.

Can someone try something like this:

#if MAC_OS_X_VERSION_MIN_REQUIRED < 1070

[do someStuff:here andHere];

#endif

and see if it builds on 10.6? If so, send me a patch and I'll test it on 
10.11 and commit if it works. I have no access to 10.6.


Thanks,
Kevin

--
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com

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

Permission denied, "pkg" phase

[Craig Treleaven]

How do I get elevated privileges in a “pre-pkg” block?

In a thread a couple of days ago, it was pointed out that “pkg” and “mpkg” are 
phases and that one can have a pre-pkg or post-mpkg block.  I want to include a 
copy of daemondo in an mpkg and it looks like all I need to do is copy the 
executable into the destroot.  The pkg phase will then then create an installer 
component including it and mpkg will add that to the meta package.  I’ve been 
testing this with the gforth port just to work out the concept.

The offending block is:

pre-pkg {
  xinstall -m 644 ${prefix}/bin/daemondo ${destroot}${prefix}/bin/
}

resulting in:

Error: org.macports.pkg for port gforth returned: xinstall: Unable to create 
new file for: 
/opt/local/var/macports/build/_Users_craigtreleaven_mp_ports_lang_gforth/gforth/work/destroot/opt/local/bin//daemondo,
 Permission denied
DEBUG: Error code: NONE

I’ve tried adding:

pkg.asroot  yes

to my portfile but that seems to be unrecognized.

Is there a way around this?

Craig


Please excuse typos--sent from my iPhone.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Updating tk +quartz failed on Snow Leopard

[Ryan Schmidt]

On Aug 25, 2016, at 8:38 PM, Ken Cunningham  
wrote:
> 
> I agree - preprocessor macros are the upstream way to solve this. I've seen 
> several ports that use this method...
> 
> Ken
> 
> 
> Begin forwarded message:
> 
>> From: Ken Cunningham 
>> Date: August 25, 2016 11:14:37 AM PDT
>> To: Mojca Miklavec 
>> Cc: k...@codebykevin.com
>> Subject: Re: Updating tk +quartz failed on Snow Leopard
>> 
>> also, this Apple document would appear to be of potential use:
>> 
>> 
>> 
>> especially down at this part:
>> 
>> Listing 3-3  Using preprocessor directives for conditional compilation
>> #ifdef __MAC_OS_X_VERSION_MAX_ALLOWED
>> // code only compiled when targeting OS X and not iOS
>> // note use of 1050 instead of __MAC_10_5
>> #if __MAC_OS_X_VERSION_MAX_ALLOWED >= 1050
>> if (CGColorCreateGenericCMYK != NULL) {
>> CGColorCreateGenericCMYK(0.1,0.5.0.0,1.0,0.1);
>> } else {
>> #endif
>> // code to create a color object with earlier technology
>> #if __MAC_OS_X_VERSION_MAX_ALLOWED >= 1050
>> }
>> #endif
>> #endif
>> }
>> 
>> 
>> Ken
>> 
>> 
>> On 2016-08-25, at 10:06 AM, Ken Cunningham wrote:
>> 
>>> Perhaps these AvailabilityMacros might be of use here. I've seen them used 
>>> for conditional code in other ports. This example was for 10.9, but you'd 
>>> presumably use a slightly different version of the code for 10.6, or  10.7+.
>>> 
>>> /usr/include/AvailabilityMacros.h
>>> 
>>> eg: 
>>> 
>>> 
>>> #if MAC_OS_X_VERSION_MIN_REQUIRED >= MAC_OS_X_VERSION_10_9
>>>  
>>> #else
>>>  
>>> #endif
>>> 
>>> 
>>> Ken

I just haven't researched whether one is supposed to use 
MAC_OS_X_VERSION_MIN_REQUIRED or MAC_OS_X_VERSION_MAX_ALLOWED or 
__MAC_OS_X_VERSION_MAX_ALLOWED or something else.


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

Re: Updating tk +quartz failed on Snow Leopard

[Joshua Root]

On 2016-8-26 11:21 , Ryan Schmidt wrote:


On Aug 25, 2016, at 11:38 AM, Ryan Schmidt wrote:


tk isn't the first program to need to deal with Retina displays. Can we find 
any other program that uses NSWindow's backingScaleFactor selector and see how 
it handles it?


I missed these warning from the original post:

warning: ‘NSWindow’ may not respond to ‘-backingScaleFactor’
warning: (Messages without a matching method signature
warning: will be assumed to return ‘id’ and accept
warning: ‘...’ as arguments.)

I *think* if we could use the 10.7 SDK, then it would know that 
-backingScaleFactor actually returns a float and wouldn't complain. But we 
can't use the 10.7 SDK because it's not in Xcode 3.2.6. Wikipedia says it's in 
Xcode 4.1 and later, but I don't see it in Xcode 4.1 or 4.2 for Snow Leopard. 
Maybe it's only in Xcode 4.1 and 4.2 for Lion. (They were different.)

I think that code just has to be excluded for 10.6 and earlier with 
preprocessor directives.


Or you could use a category to add a declaration of backingScaleFactor 
(appropriately #ifdef'd for < 10.7 only of course.)




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

Re: Updating tk +quartz failed on Snow Leopard

[Ryan Schmidt]

On Aug 25, 2016, at 11:38 AM, Ryan Schmidt wrote:

> tk isn't the first program to need to deal with Retina displays. Can we find 
> any other program that uses NSWindow's backingScaleFactor selector and see 
> how it handles it?

I missed these warning from the original post:

warning: ‘NSWindow’ may not respond to ‘-backingScaleFactor’
warning: (Messages without a matching method signature
warning: will be assumed to return ‘id’ and accept
warning: ‘...’ as arguments.)

I *think* if we could use the 10.7 SDK, then it would know that 
-backingScaleFactor actually returns a float and wouldn't complain. But we 
can't use the 10.7 SDK because it's not in Xcode 3.2.6. Wikipedia says it's in 
Xcode 4.1 and later, but I don't see it in Xcode 4.1 or 4.2 for Snow Leopard. 
Maybe it's only in Xcode 4.1 and 4.2 for Lion. (They were different.)

I think that code just has to be excluded for 10.6 and earlier with 
preprocessor directives. Here's an example of how another project did that:

https://gist.github.com/zwaldowski/3388768

I don't know if those are the correct defines to use.

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

Re: Goodbye Mac OS Forge, hello GitHub

[Kuba Ober]

On Sat, Aug 20, 2016 at 4:11 AM, Joshua Root  wrote:

>
> I share these concerns and brought them up during the discussions. And TBH
> I think Mercurial is a better tool. But we did come to a consensus that
> GitHub is overall the best choice at this time.
>

As I see it, mercurial doesn't have feature parity with git. E.g. I
consider the index to be an indispensable feature. Combine that with
smartgit and you've got a system that lets you check in lean, to-the-point
changes. It's an indispensable part of my workflow. First-class stashes
(not a bolt on) are another life-saver. I had an opportunity to port
repositories at work from subversion to either mercurial or git. After a
short evaluation, git became a no-brainer.

Yes, if all you're using in a workflow are mercurial features, then git
seems like an unnecessary complication, although it does have feature
parity with mercurial AFAIK. Once you start using all that git has to
offer, there's no going back - at least not for me. These days for
repositories that aren't monstrous (i.e. gigabytes worth of content), I use
git to access subversion repos as well.


> And as Mark mentioned, one of the advantages of a DVCS is that the full
> repository history isn't locked away on a single server, so if GitHub goes
> down or turns evil, we can easily pack up and go elsewhere. (This of
> applies to source code but not to things like issues, which is another good
> reason to keep them on our own server.)
>

Subversion repositories can be cloned with full history. An easy way to do
it is using git :)

I better don my Nomex now and slink away ;)

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

Re: r151951: Wrong compiler dependencies of llvmlite

[Ryan Schmidt]

> On Aug 25, 2016, at 9:14 AM, Mojca Miklavec  wrote:
> 
> Hi,
> 
> The changes from
>http://trac.macports.org/changeset/151951
> don't work to well. I guess that the same compiler should be used to
> build the ports as the one you are linking against.
> 
> See an example of the failed build:
> https://build.macports.org/builders/ports-10.11_x86_64-builder/builds/2882
> (it fails on all the buildbots).

This was filed as https://trac.macports.org/ticket/52102 and fixed.

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

Re: Updating tk +quartz failed on Snow Leopard

[Ryan Schmidt]

> On Aug 25, 2016, at 5:44 AM, Mojca Miklavec  wrote:
> 
> Hi,
> 
> I'm moving the discussion from the user mailing list to the developer
> one, hoping to catch attention of more experienced developers there.
> 
> To summarize.
> 
> Tk fails to compile on Snow Lepard due to the following chunk of code:
> 
>MacDrawable *macDraw = (MacDrawable *) d;
>NSWindow *win = TkMacOSXDrawableWindow(d);
>int scalefactor = 1;
>if (win && [win respondsToSelector:@selector(backingScaleFactor)]) {
>scalefactor = ([win backingScaleFactor] == 2.0) ? 2 : 1;
>}
> 
> The function backingScaleFactor has only been added in 10.7 and
> returns a floating point number.
> 
> On 10.6 the "if" sentence is false, so the "scalefactor = ..." never
> gets executed. The problem is that 10.6 believes that [win
> backingScaleFactor] returns "id" rather than a floating point number
> (it doesn't know the function after all) and throws a compile error
> because id cannot be compared with a floating point (2.0).

tk isn't the first program to need to deal with Retina displays. Can we find 
any other program that uses NSWindow's backingScaleFactor selector and see how 
it handles it?

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

updated port of LaTeXML

[Bruce Miller]

Hello mac developers;
  Could someone please commit the Portfile in
https://trac.macports.org/ticket/51818 ?

It updates to upstream 0.8.2, upgrades
the perl dependency to 5.24 (per https://trac.macports.org/ticket/52081 )
and fixes https://trac.macports.org/ticket/47972
and https://trac.macports.org/ticket/49507
which can both be closed.

Thanks!
bruce

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

r151951: Wrong compiler dependencies of llvmlite

[Mojca Miklavec]

Hi,

The changes from
http://trac.macports.org/changeset/151951
don't work to well. I guess that the same compiler should be used to
build the ports as the one you are linking against.

See an example of the failed build:
 https://build.macports.org/builders/ports-10.11_x86_64-builder/builds/2882
(it fails on all the buildbots).

Mojca

(I'm not subscribed to the changesets, so I cannot "reply" like Ryan
usually does.)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Updating tk +quartz failed on Snow Leopard

[Mojca Miklavec]

On 25 August 2016 at 12:44, Mojca Miklavec wrote:
>
> and tried to replace
> scalefactor = ([[win backingScaleFactor] floatValue] == 2.0) ? 2 : 1;
> with
> scalefactor = ([win backingScaleFactor] == 2.0) ? 2 : 1;

... The other way around.

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

Re: Updating tk +quartz failed on Snow Leopard

[Mojca Miklavec]

Hi,

I'm moving the discussion from the user mailing list to the developer
one, hoping to catch attention of more experienced developers there.

To summarize.

Tk fails to compile on Snow Lepard due to the following chunk of code:

MacDrawable *macDraw = (MacDrawable *) d;
NSWindow *win = TkMacOSXDrawableWindow(d);
int scalefactor = 1;
if (win && [win respondsToSelector:@selector(backingScaleFactor)]) {
scalefactor = ([win backingScaleFactor] == 2.0) ? 2 : 1;
}

The function backingScaleFactor has only been added in 10.7 and
returns a floating point number.

On 10.6 the "if" sentence is false, so the "scalefactor = ..." never
gets executed. The problem is that 10.6 believes that [win
backingScaleFactor] returns "id" rather than a floating point number
(it doesn't know the function after all) and throws a compile error
because id cannot be compared with a floating point (2.0).

I found a potential workaround at
http://stackoverflow.com/questions/307128/how-do-i-cast-id-to-a-float

and tried to replace
scalefactor = ([[win backingScaleFactor] floatValue] == 2.0) ? 2 : 1;
with
scalefactor = ([win backingScaleFactor] == 2.0) ? 2 : 1;

This avoids the build error on 10.6, but apparently doesn't compile on
10.11 at all.

> .../tk/unix/../macosx/tkMacOSXXStubs.c:901:18: error:
>   bad receiver type 'CGFloat' (aka 'double')

This is easy to patch in MacPorts only. We just remove that code when
compiling on 10.6 or earlier and we are done (we can already do that
straight away).

But it would be nice to have a proper patch for upstream.

An easy workaround would be to simply use something like
#if __MAC_OS_X_VERSION_MAX_ALLOWED >= 1070
rather than testing for "respondsToSelector", but if I understand
correctly that would have a slight drawback than an application
compiled on 10.6 would not be able to work as nicely on a Retina
display. I'm not an ObjectiveC speaker myself, but I remember Jeremy
H. mentioning that several times.

Then again, given that it currently doesn't compile on 10.6 at all,
there's probably not much need for that kind of functionality (=
compile on 10.6 & get a perfect app with all the latest features on
10.11) anyway. MacPorts wouldn't care because we only ever compile for
the same platform.

If anyone has any clue about how to fix the upstream source code to
make it work on both 10.6 as well as the latest OS, I would be
grateful for any hints.

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