Re: [77027] trunk/dports/python

[Ryan Schmidt]

On Mar 18, 2011, at 03:00, j...@macports.org wrote:

> Revision: 77027
>  http://trac.macports.org/changeset/77027
> Author:   j...@macports.org
> Date: 2011-03-18 01:00:46 -0700 (Fri, 18 Mar 2011)
> Log Message:
> ---
> py-macholib, py-py2app-devel: adjust deps to avoid trying to install both 
> py-modulegraph and py-modulegraph-devel on a fresh install (#28816)

Actually, I was going to wonder if we shouldn't perhaps make the 
py*-modulegraph-devel ports replaced_by py*-modulegraph, since the -devel ports 
are currently older.


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

Re: [77027] trunk/dports/python

[Joshua Root]

On 2011-3-18 19:04 , Ryan Schmidt wrote:
> 
> On Mar 18, 2011, at 03:00, j...@macports.org wrote:
> 
>> Revision: 77027
>>  http://trac.macports.org/changeset/77027
>> Author:   j...@macports.org
>> Date: 2011-03-18 01:00:46 -0700 (Fri, 18 Mar 2011)
>> Log Message:
>> ---
>> py-macholib, py-py2app-devel: adjust deps to avoid trying to install both 
>> py-modulegraph and py-modulegraph-devel on a fresh install (#28816)
> 
> Actually, I was going to wonder if we shouldn't perhaps make the 
> py*-modulegraph-devel ports replaced_by py*-modulegraph, since the -devel 
> ports are currently older.

Feel free.

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

Re: Use configure.ldflags-delete instead of configure.ldflags?

[Anders F Björklund]

Ryan Schmidt wrote:

 and 'ldflags' should (imho) be safe for a port to simply reset. This seems 
 demonstrative of the problems that can emerge with base implicitly setting 
 environmental variables and other build-time arguments; it's much harder 
 to control them directly from a port when you need something different.
>>> 
>>> Then how would you suggest the user's need -- of building all libraries 
>>> with maximum header padding -- be met?
>> 
>> "port install inkscape" ?
> 
> ...how does that meet the need? To my knowledge, by default, software does 
> not build using the maximum header padding flag. This thread is the 
> discussion about adding that flag to base.
> 

"I am trying to have "-Xlinker -headerpad_max_install_names" added to all 
ports' ldflags by modifying 
/opt/local/share/macports/Tcl/port1.0/portconfigure.tcl"

"I managed to build the dependencies for inkscape (the reason why I am doing 
all this) with "-Wl,-headerpad_max_install_names" added to portconfigure.tcl 
without apparent problem."

So it seems like the main reason to add the maximum header padding is so that 
one can modify the libraries with install_name_tool to be able to relocate them 
to outside MacPorts for inclusion in an application bundle ?

If instead including the application in MacPorts, there is no need for such 
relocation... Of course, there might be other reasons to modify the ldflags. 
Just like there are some valid reasons to modify cflags.

--anders

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

Re: Use configure.ldflags-delete instead of configure.ldflags?

[Ryan Schmidt]

On Mar 18, 2011, at 03:41, Anders F Björklund wrote:

> Ryan Schmidt wrote:
> 
> and 'ldflags' should (imho) be safe for a port to simply reset. This 
> seems demonstrative of the problems that can emerge with base implicitly 
> setting environmental variables and other build-time arguments; it's much 
> harder to control them directly from a port when you need something 
> different.
 
 Then how would you suggest the user's need -- of building all libraries 
 with maximum header padding -- be met?
>>> 
>>> "port install inkscape" ?
>> 
>> ...how does that meet the need? To my knowledge, by default, software does 
>> not build using the maximum header padding flag. This thread is the 
>> discussion about adding that flag to base.
> 
> "I am trying to have "-Xlinker -headerpad_max_install_names" added to all 
> ports' ldflags by modifying 
> /opt/local/share/macports/Tcl/port1.0/portconfigure.tcl"
> 
> "I managed to build the dependencies for inkscape (the reason why I am doing 
> all this) with "-Wl,-headerpad_max_install_names" added to portconfigure.tcl 
> without apparent problem."
> 
> So it seems like the main reason to add the maximum header padding is so that 
> one can modify the libraries with install_name_tool to be able to relocate 
> them to outside MacPorts for inclusion in an application bundle ?
> 
> If instead including the application in MacPorts, there is no need for such 
> relocation... Of course, there might be other reasons to modify the ldflags. 
> Just like there are some valid reasons to modify cflags.

Yes, I believe the user wants to relocate MacPorts-built libraries using 
install_name_tool. This is not always possible without increased header padding.

We may not particularly support what this user is doing, but we may very well 
want to support doing this when we start building and distributing binary 
packages, so that they could be relocated to whatever prefix the user installed 
MacPorts to.

Therefore we may want to add the flags for max header padding to the default 
configure.ldflags in MacPorts as suggested. This would necessitate revisiting 
portfiles that currently clear configure.ldflags under the assumption that only 
-L flags are in there.

So, I return to your initial response:

> and 'ldflags' should (imho) be safe for a port to simply reset. This 
> seems demonstrative of the problems that can emerge with base implicitly 
> setting environmental variables and other build-time arguments; it's much 
> harder to control them directly from a port when you need something 
> different.
>> 

and ask you to clarify your objection to this proposal.


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

Re: Use configure.ldflags-delete instead of configure.ldflags?

[Ryan Schmidt]

On Mar 16, 2011, at 04:47, Rainer Müller wrote:

> On 03/15/2011 02:13 AM, Ryan Schmidt wrote:
>>> How about the addition of "-Xlinker -headerpad_max_install_names" as a
>>> default in portconfigure.tcl? Would macport consider it?
>> 
>> We could consider that. I wonder if there are any negative implications for 
>> any ports? Have you already been trying this on many ports, with positive 
>> results?
> 
> Wouldn't this give the wrong impression that libraries are relocatable?
> This might be true for some of them, but definitely not for all.

Can you give an example of a library that would not be relocatable?


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

Re: Use configure.ldflags-delete instead of configure.ldflags?

[Anders F Björklund]

Ryan Schmidt wrote:

> We may not particularly support what this user is doing, but we may very well 
> want to support doing this when we start building and distributing binary 
> packages, so that they could be relocated to whatever prefix the user 
> installed MacPorts to.

If you are planning to use the current "archives" to do so, you could have a 
problem with the prefix being included in the file paths. Easy enough to "cd" 
when extracting, maybe it's mostly pathname bloat (an extra /opt/local per 
file).

I think that relocatable packages are great BTW, just a much bigger order than 
adding LDFLAGS ? Supporting that properly would be a worthy challenge, and open 
up for building packages as non-root (to not prefix /Users/name/.macports).


> Therefore we may want to add the flags for max header padding to the default 
> configure.ldflags in MacPorts as suggested. This would necessitate revisiting 
> portfiles that currently clear configure.ldflags under the assumption that 
> only -L flags are in there.

That's still a bug, though.

> So, I return to your initial response:
> 
>> and 'ldflags' should (imho) be safe for a port to simply reset. This 
>> seems demonstrative of the problems that can emerge with base implicitly 
>> setting environmental variables and other build-time arguments; it's 
>> much harder to control them directly from a port when you need something 
>> different.
>>> 
> 
> and ask you to clarify your objection to this proposal.

Don't think that was mine.

I'm all for hacking out random environment variables in ports. :-)
But the problem itself is the same as with CFLAGS versus optflags ?
Sometimes you just want to avoid -O3 etc, but remove "needed" flags.

But you *could* do an LD wrapper, just like one can wrap CC for arch.
(i.e. do an "ld" stub that would add a -headerpad_max_install_names,
just like one can have "gcc" wrappers that are prefixed with triplets)

--anders

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

Re: Use configure.ldflags-delete instead of configure.ldflags?

[Anders F Björklund]

Ryan Schmidt wrote:

> On Mar 16, 2011, at 04:47, Rainer Müller wrote:
> 
>> On 03/15/2011 02:13 AM, Ryan Schmidt wrote:
 How about the addition of "-Xlinker -headerpad_max_install_names" as a
 default in portconfigure.tcl? Would macport consider it?
>>> 
>>> We could consider that. I wonder if there are any negative implications for 
>>> any ports? Have you already been trying this on many ports, with positive 
>>> results?
>> 
>> Wouldn't this give the wrong impression that libraries are relocatable?
>> This might be true for some of them, but definitely not for all.
> 
> Can you give an example of a library that would not be relocatable?

The usual examples are the ones that dlopen others with absolute paths,
or try to read configuration or resources from a hardcoded location...

But there are numerous libraries using build-time rather than run-time
configuration. And things like @executable_path don't work as strings

--anders

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

Re: Use configure.ldflags-delete instead of configure.ldflags?

[Daniel J. Luke]

On Mar 18, 2011, at 4:57 AM, Ryan Schmidt wrote:
> 
>> and 'ldflags' should (imho) be safe for a port to simply reset. This 
>> seems demonstrative of the problems that can emerge with base implicitly 
>> setting environmental variables and other build-time arguments; it's 
>> much harder to control them directly from a port when you need something 
>> different.
> 
> and ask you to clarify your objection to this proposal.

that was from landonf

I don't know specifically what he was referring to, but it's easy enough to 
think of a situation where there could be problems.

Imagine a Portfile that currently clears LDFLAGS because anything in that 
environment variable causes the build to fail or to do unexpected things.

If instead, the portfile author has to clear the individual environment 
settings, then each time base/ changes, that Portfile needs to change as well.

There are other issues, too - when we didn't set LDFLAGS/CFLAGS in base/, 
library ports that didn't need to depend on things in $prefix didn't have the 
problem of mistakenly linking to a previously installed version.

--
Daniel J. Luke  
 
++  
  
| * dl...@geeklair.net * |  

| *-- http://www.geeklair.net -* |  

++  
  
|   Opinions expressed are mine and do not necessarily   |  

|  reflect the opinions of my employer.  |  

++



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

Re: Use configure.ldflags-delete instead of configure.ldflags?

[Rainer Müller]

On 03/18/2011 09:58 AM, Ryan Schmidt wrote:
> Can you give an example of a library that would not be relocatable?

As Anders already said, anything that uses data files from
${prefix}/share or ${prefix}/etc and has these paths hardcoded for this
purpose.

Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: Use configure.ldflags-delete instead of configure.ldflags?

[Anders F Björklund]

Rainer Müller wrote:

> On 03/18/2011 09:58 AM, Ryan Schmidt wrote:
>> Can you give an example of a library that would not be relocatable?
> 
> As Anders already said, anything that uses data files from
> ${prefix}/share or ${prefix}/etc and has these paths hardcoded for this
> purpose.

And that's on a *good* day. Usually it's "/usr/share" and "/etc".
(looking at you, glib. Thanks for that $XDG_DATA_DIRS requirement)

Some of the more subtle points are the ones that get clever and
presume that everything is installed to the *same* directory...
So they would use the prefix of "foo", to get the prefix of "bar".
Which of course works just fine if both are /usr, but not always.

MacPorts usually relocates everything to the same directory anyway
(i.e. by linking to the "software" images, rather than referring)
But other software that uses one prefix per program has problems.
Or one prefix per program-version, even (to allow multiple installs)

I think most of the hardcoded "/opt/local" strings have been fixed.
Making ${prefix} a run-time thing, that is definitely still TODO...


There was an over-engineered solution called "binreloc" for this,
that was for Linux but also portable to Solaris/Darwin (not BSD ?).

http://www.autopackage.org/docs/binreloc/
-> _NSGetExecutablePath(path, &path_len);

--anders

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

Re: Use configure.ldflags-delete instead of configure.ldflags?

[Jeff Johnson]

On Mar 18, 2011, at 11:15 AM, Anders F Björklund wrote:

> Rainer Müller wrote:
> 
>> On 03/18/2011 09:58 AM, Ryan Schmidt wrote:
>>> Can you give an example of a library that would not be relocatable?
>> 
>> As Anders already said, anything that uses data files from
>> ${prefix}/share or ${prefix}/etc and has these paths hardcoded for this
>> purpose.
> 
> And that's on a *good* day. Usually it's "/usr/share" and "/etc".
> (looking at you, glib. Thanks for that $XDG_DATA_DIRS requirement)
> 
> Some of the more subtle points are the ones that get clever and
> presume that everything is installed to the *same* directory...
> So they would use the prefix of "foo", to get the prefix of "bar".
> Which of course works just fine if both are /usr, but not always.
> 
> MacPorts usually relocates everything to the same directory anyway
> (i.e. by linking to the "software" images, rather than referring)
> But other software that uses one prefix per program has problems.
> Or one prefix per program-version, even (to allow multiple installs)
> 
> I think most of the hardcoded "/opt/local" strings have been fixed.
> Making ${prefix} a run-time thing, that is definitely still TODO...
> 

One can do relative paths from argv[0] to find data directories "portably"
independent of PATH. You do have to be a bit careful hos that is done,
because you can no longer just copy an executable once argv[0]
is used to find attached data/configuration. But there's a large
class of executables (imho) that are built, installed, and seldom copied.

> 
> There was an over-engineered solution called "binreloc" for this,
> that was for Linux but also portable to Solaris/Darwin (not BSD ?).
> 
> http://www.autopackage.org/docs/binreloc/
> -> _NSGetExecutablePath(path, &path_len);
> 

Yes autopackage is/was horrendously over-engineered.

But the problem still remains, particularly with 3rd party excutables
built out of tree. NixOS has a rather straightly-forward solution
to path independence. Not quite run-time, but cleanly separated from The Build.

And the relevance to MacPorts and Mach-O is that the problem is the same
(in fact worse on MacPorts) and the engineering approaches to solving
are the same even if the implementations I just mentioned are irrelevant.

73 de Jeff
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Devtools opensource release

[Daniel J. Luke]

http://opensource.apple.com/release/developer-tools-40/

so ... do we build/ship our own set of tools?

(it would be a bunch of new/extra work, but we could at least fix the 
/usr/local problem)

--
Daniel J. Luke  
 
++  
  
| * dl...@geeklair.net * |  

| *-- http://www.geeklair.net -* |  

++  
  
|   Opinions expressed are mine and do not necessarily   |  

|  reflect the opinions of my employer.  |  

++



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

Re: Devtools opensource release

[Rainer Müller]

On 03/18/2011 04:40 PM, Daniel J. Luke wrote:
> http://opensource.apple.com/release/developer-tools-40/
> 
> so ... do we build/ship our own set of tools?

As far as I can see this does not include any system headers which is a
showstopper.

Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: Devtools opensource release

[Daniel J. Luke]

On Mar 18, 2011, at 12:05 PM, Rainer Müller wrote:
> 
> On 03/18/2011 04:40 PM, Daniel J. Luke wrote:
>> http://opensource.apple.com/release/developer-tools-40/
>> 
>> so ... do we build/ship our own set of tools?
> 
> As far as I can see this does not include any system headers which is a
> showstopper.

oh yeah, looks like I got excited too soon :-\

--
Daniel J. Luke  
 
++  
  
| * dl...@geeklair.net * |  

| *-- http://www.geeklair.net -* |  

++  
  
|   Opinions expressed are mine and do not necessarily   |  

|  reflect the opinions of my employer.  |  

++



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

Re: Devtools opensource release

[William Siegrist]

On Mar 18, 2011, at 9:05 AM, Rainer Müller wrote:

> On 03/18/2011 04:40 PM, Daniel J. Luke wrote:
>> http://opensource.apple.com/release/developer-tools-40/
>> 
>> so ... do we build/ship our own set of tools?
> 
> As far as I can see this does not include any system headers which is a
> showstopper.


Maybe the Mac OS X releases[1] contain the headers you need? If you think the 
DevTools releases should have matching headers, let me know and I will look 
into it. 

[1] http://opensource.apple.com/release/mac-os-x-1066/

-Bill


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

Re: Devtools opensource release

[Mark Anderson]

Also, do the raw system frameworks include the headers?  I don't have a
un-developer-tooled machine to look.

We could always resort to class-dump. :-)

Mark

On Fri, Mar 18, 2011 at 12:45 PM, William Siegrist wrote:

>
> On Mar 18, 2011, at 9:05 AM, Rainer Müller wrote:
>
> > On 03/18/2011 04:40 PM, Daniel J. Luke wrote:
> >> http://opensource.apple.com/release/developer-tools-40/
> >>
> >> so ... do we build/ship our own set of tools?
> >
> > As far as I can see this does not include any system headers which is a
> > showstopper.
>
>
> Maybe the Mac OS X releases[1] contain the headers you need? If you think
> the DevTools releases should have matching headers, let me know and I will
> look into it.
>
> [1] http://opensource.apple.com/release/mac-os-x-1066/
>
> -Bill
>
>
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: Abandoned port [nbsmtp]

[Andrea D'Amore]

On Fri, Mar 18, 2011 at 12:18 AM, Ryan Schmidt  wrote:
> I'm not familiar with the software.

I think very few are, I was checking a quick way to test a SMTP server.

> If you can find an updated version of nbsmtp and can update the port to that 
> version, great.

So I did in r77052.

> If not, and you'd like to declare the port dead,

Actually I thought about that and decided about upgrading, after all
this is the best condition possible, it's a software whose Portfile
you'll never need to upgrade again, bugs apart.


-- 
Andrea
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Google Summer of Code 2011: MacPorts has been accepted

[Rainer Müller]

Hello,

this is just a quick announcement that MacPorts once again has been
accepted into the Google Summer of Code program. If you are not already
familiar with this: Google pays students to work on various Open Source
projects over the summer. It is also a good start for students with Open
Source development. MacPorts is taking part in this program every year
since 2007.

As a student accepted into or enrolled in a college, university or
masters programs you may apply to work on MacPorts for this summer and
get $5000 USD as compensation. There is no requirement for any
contribution to MacPorts or other Open Source projects before, it is
only expected that you show us the motivation to work on your task.

But to support the students we also need mentors, who will discuss the
task with the student and give advice during implementation. Especially
there is nobody yet available for the MacPorts GUI, which has been
developed as part of the program in the last years. It would be nice to
be able to improve this even more so we can finally include it with the
disk image install. I hope there is an interested Cocoa developer among us.

We have a list of ideas with possible tasks for MacPorts and additional
information about the application process:
  http://trac.macports.org/wiki/SummerOfCode

Looking forward to yet another Summer of Code,
Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

darwin/10.7.1

[Takeshi Enomoto]

Hi,

A user reported a problem in building g95 but I could not reproduce the problem 
(#28782).

His main.log indicates that he uses a new kernel probably shipped with new Mac 
Book Pro (Thunderbolt).

:debug:main OS darwin/10.7.1 (Mac OS X 10.6) arch i386

I could fix Portfile by detecting 10.7.x if there is ``$os.minor''.
Should I use $os.version? What is the version number?

Someone says the next update of Snow Leopard will also
use 10.7.x kernel.


Takeshi
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: Bumping other py*-lint when bumping py26-lint

[Blair Zajac]

On Mar 15, 2011, at 11:37 AM, Joshua Root wrote:


On 2011-3-16 04:17 , Blair Zajac wrote:
PS Is there a list of macport logins and real names, so we don't  
have to say "Hey you" :) ?





Thanks!

Blair

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