py26-numpy +gcc44 requires gcc45 variant of atlas

[Jeff Singleton]

Well ...

I can honestly say, I get all of your points.  Not that I didn't before, but
it is definitely clear now.

I am even less of a developer that the newest maintainer here, so I can only
point out what doesn't seem correct, or isn't working.  I can read code, and
on rare occasions fix minor issues derived from error messages.

Ryan ... I say I should be able to choose which Arch that I want to build
under if my hardware supports it, sometimes it isn't proper to just accept
whatever the compiler chooses.  Sometimes preference of the end user should
dictate how things should and shouldn't work...not the hardware.  If I have
a need for 32-bit, then that is my need and no one should tell me that I
can't build code in 32 bit on hardware that is natively 64 bit...if the
compiler supports it, then I should be able to tell it to do so.

As for the manpower thing ... well I guess that is something that may not
change or could change dramatically. Possibly a bit of marketing of MacPorts
might attract some talent.  Yet, as far as I know, every Linux distribution
aside from Redhat and Suse is a volunteer based community of
developers/maintainers...and even Redhat and Suse have community driven
forks that help drive the development of the mainstream distros.  So what
makes MacPorts any different from all those others, is it popularity or a
lack thereof?  Do enough people know about MacPorts and how closely it
relates to BSD ports? I suppose if just waiting around for someone to
stumble across MacPorts and see they can offer some talent to maintaining
some ports is ok, then MacPorts will just continue to move at the pace it is
now.

Besides, everyone can't be a coder, someone needs to actually use this stuff
or else no one would ever know anything was broken.  Developers always seem
to take offense when a user points out a flaw, and thus deeming the
reporting user as point man for patching or updating the code themselves.

The fact is, coding and maintaining said code is what you developers do
best.  Information Security is what I do best....and as such, I would never
divert an issue needing my attention on to the person reporting the issue.
Because of the nature of my work, doing so would almost guarantee that the
network I am protecting is exposed.

So .. if upstream is deemed responsible for fixing a code issue then how do
we bring this to their attention?  Are the Trac bugs ever viewed by upstream
or referenced in other bugs opened with the upstream issue tracker?  How can
I escalate a Trac bug from MacPorts to the upstream owners of the code in
question?

-- 


On Wed, Sep 15, 2010 at 9:42 AM, Michael Dickens <michaelld at macports.org>wrote:

> On Sep 14, 2010, at 2:41 PM, Jeff Singleton wrote:
> > How could "I" be compiling for one arch and then linking another ... I'm
> using MacPorts.  I would assume that if a Port has support for universal,
> then MP would adhere to this and build universal.
>
> As pointed out by Ryan, many MP developers / maintainers do not test for
> +universal (or, for that matter, other variants).  I'm certainly guilty of
> not doing it in the past, but I'm testing for it now & will continue to do
> so in the future as I add / fix ports.  All of that said, MacPorts is not
> infallible as an install system -- we as developers / maintainers do the
> best we can, I think, but there's always room for doing it better somewhere.
>  I would guess that none of us work exclusively on MP, instead giving it
> time & attention as our work load allows -- so, don't expect miracles.  MP
> works well overall, and we continue to work to improve both port as well as
> the portfiles.
>
> > If the compiling from .c to .o is done as 32-bit, but trying to link
> 64-bit, then I would say that the maintainer of said port needs to look at
> this and fix it.
>
> Many of these types of issues should really be fixed upstream (at the
> developer of the project), not by us maintainers of the ports.  Let me
> elaborate via my current issue:
>
> In this case, the issue is in how numpy's setup.py does its internal
> "configure" checking -- verifying that the compiler works & finding headers
> and such --, not directly in how MacPorts is interfacing with it.  From what
> I can tell -- and, I really haven't figured out where in the setup.py
> scripts all these testing takes place -- numpy does the following test
> (among others; this is the first one that involves linking AFAICT):
>
> 1) create conftest.c
> 2) ${CC} -c ${CFLAGS} -o conftest.o conftest.c
> 3) Change CFLAGS -> CFLAGS2: if the compiler is Apple's GCC, then it copies
> any -arch flag, but if it's not Apple's GCC then it clears out the CFLAGS2.
> 4) ${CC} ${CFLAGS2} -o conftest conftest.o
>
> So, when port tries to build numpy as 32-bit by setting "CFLAGS=-m32"
> (because port is not using Apple's GCC for this purpose, and thus this flag
> is the only way to compile as 32-bit), step (2) creates a 32-bit .o file but
> step (3) clears out CFLAGS2 & thus step (4) fails because the default link
> arch is x86_64 & none of the provided .o files are of that architecture.
>  This is not the port maintainer's fault; it's the upstreams'.
>
> So, there are 2 issues here:
>
> A) GCC (Apple's of not) should be "smart enough" to check through all of
> the provided .o files and libraries to auto-determine the arch setting if
> just one is possible; and, erroring out if not.  Doing so is -way- beyond
> the expectation of your typical port maintainer.
>
> B) Numpy's setup.py scripts should check for arch flags in C*FLAGS and
> carry them over for this and other linking tests.  Again, doing so is also
> -way- beyond the expectation of your typical port maintainer.
>
> Arch flags vary greatly between OS/Compiler types.  setup.py handles -a
> lot- of different types, much as GNU's autotools, QMake, and CMake do; there
> is no perfect, generic way to do this "configure" oriented testing. - MLD
>

Your HTML signature here
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20100915/77dc5dd7/attachment.html>