Re: variant or platform
On 15 Jul 2007, at 23:53, Anders F Björklund wrote:
Ryan Schmidt wrote:
Seems like all the current ports with x86 or intel as the
arch are
either wrong or typos, though... darwin x86 should be darwin
i386,
I still say that this needs to be examined and evaluated
individually for each port. If nobody's complaining about these
ports, then maybe whatever's being done in the darwin x86 platform
selector isn't necessary for Intel Macs at all, and might in fact
be harmful.
It's just 7 ports, but so far it all looks like they should be
changed.
For example, mpfr has a section platform darwin x86, but it also
has an identical section platform darwin i386, so the port
maintainer, Vincent, should be asked why this is duplicated. I'm
Cc'ing him on this email.
I have no idea what kind of Darwin system would return x86 in uname.
The list at http://wiki.tcl.tk/1649 only mentions i386 and i386...
OpenDarwin did return x86 while Mac OS X returns i386; so the 'x86'
stuff is/was for OpenDarwin while 'i386' is the Mac OS X Intel stuff.
So please do NOT replace x86 by i386 by default - this is not an
error to be corrected this way. If no one complains, we may just
remove the x86 ones as there is no OpenDarwin distribution anymore.
And xgalaga has a section platform darwin x86 which should
clearly be platform darwin i386, and I've changed that now, but
the port doesn't build on Intel Macs anyway because it uses (and
seems maybe to require) gcc 3.3.
See other email... There is no such i386 gcc-3.3 for Mac OS X 10.4 ?
and the one (1) port with darwin intel is just plain wrong IMHO.
Ah -- darwin intel -- that's why I didn't find it before. Got it
now: it's libdnsres. I'm Cc'ing the maintainer, Mark, since he
should have a say in this, but I agree, this should be platform
darwin i386. I think he should also remove the unnecessary CFLAGS
and LDFLAGS definitions.
Actually it should be platform darwin 8 i386, but most likely it
should be updating the config.sub and config.guess or so instead ?
They should most likely be *standardized* to be powerpc or i386,
even though the aliases ppc and x86 are theoretically valid too
(for example Darwin 6-7 was i386, Darwin 8-9 are i686, both: x86)
I don't know what you mean by all of this.
The triplets are:
i386-apple-darwin6
i386-apple-darwin7
i686-apple-darwin8
i686-apple-darwin9
Other operating systems, like Fedora, went through similar changes
as well.
(whether arch actually returns i386 or i686 depends on some other
factors)
I'm on darwin 8 now, and uname returns i386, and platform x86
sections definitely do not get executed by MacPorts on an Intel
Mac currently. If you're suggesting that MacPorts base could be
changed so that x86 would also work on Intel Macs, then I again
reiterate that I believe x86 is being used in several ports right
now in an attempt to target non-Macs. If such a change were made
to base, those ports would start failing on Intel Macs.
I meant that i386/i686/x86 are all the same thing, and i386 is
the name.
Optimizations for certain processors are done elsewhere anyway,
here it
is just talking about the generic architecture - Intel x86 or
PowerPC ?
It's easy to tweak port.tcl to return i386 for any x86 or i686
machines from tcl_platform, just as it is currently returns
powerpc
for the hopelessly silly `uname -m` return value of Power
Macintosh...
It might have been clearer if we had tweaked i386, i686, and
x86 to be just intel, but I'm not sure if we want to go to all
the trouble to do that now.
I prefer the shorter x86 and ppc myself, but it doesn't matter much.
The current arch names of i386 and powerpc works just as well,
but if you want to introduce the extra alias intel for i386 then
do...
If you want this done 100% correctly, I'd recommend ia32 (Intel
Architecture 32), aa64 (AMD Architecture 64), ppc32 and ppc64 -
and of course 'arm32'... ;)
The suggested port platform info command could help people
determine
what values to put into their platform variants, but for the current
common target it's probably enough to make a list of available
ones ?
I'm not sure what you mean here? What suggested port platform
info command?
I formalized the discussion we had earlier into a Trac ticket, #12302
Basically it returns something that would work if put as platform {}
--anders
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
---
Markus W. Weissmann
http://www.mweissmann.de/
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
SoC: current status (Elias Pipping)
Hi, here's the status: merge.rb is a tool that's designed to merge an arbitrary amount of single-architecture directory-trees into a single universal tree. So, given the Coreutils scenario we have four directories - ppc, ppc64, i386, and x86_64, each holding a destroot whose architecture matches its name. Here's where merge.rb comes into play. It's invoked via merge.rb ppc ppc64 i386 x86_64, you can pass an architecture more than once (doesn't matter) or leave one out (does matter), pass -v or --verbose for verbose output, perform a dryrun, change input and output directories, etc. That's all documented[1]. There are also a couple of test cases, among them Coreutils, the others include OpenSSL and LibPNG - again, all documented[1]. merge.rb is written in Ruby. That's a good thing because it makes the code easy to read (even if one does not know Ruby at all) and maintain. The code is concise, flexible and extensible. It's not a bad thing because it does not (need to) use MacPorts internals, it could even be used if MacPorts was completely rewritten and none of its current API remained. I've set up a separate subversion repository[2] for merge.rb, from time to time I also sync it with /users/pipping in the MacPorts repository. The code is made available under the MIT license.[3] [1] merge.rb's wiki: http://elias.binera.de/dokuwiki/doku.php [2] merge.rb's repo: http://elias.svn.binera.de/bin/cgi/viewvc.cgi/ [3] merge.rb's license: http://www.opensource.org/licenses/mit-license.php == Up until now I've been working on merge.rb; I think it does what it's supposed to do and it does it well. Testing is appreciated. If you've been asking yourself where those 'ppc', 'x86_64', etc. directories are supposed to come from, that's part two. merge.rb could run on a server, clients could upload their trees (built via MacPorts) to the server, etc. - the infrastructure needs to be controlled/used somehow. There are a lot of open questions and that's why I'm asking for feedback. Given merge.rb would run on a server, how would it communicate/interact with clients? Who would initiate merges or what would they be triggered by, etc. What would you want to be able to do with it? Looking forward to hearing your ideas. Kind regards, Elias Pipping ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [27155] trunk/dports/python/py-psyco/Portfile
On Jul 21, 2007, at 23:00, [EMAIL PROTECTED] wrote:
Revision: 27155
http://trac.macosforge.org/projects/macports/changeset/27155
Author: [EMAIL PROTECTED]
Date: 2007-07-21 21:00:51 -0700 (Sat, 21 Jul 2007)
Log Message:
---
make sure we set that the platform only works on intel macs
Modified Paths:
--
trunk/dports/python/py-psyco/Portfile
Modified: trunk/dports/python/py-psyco/Portfile
===
--- trunk/dports/python/py-psyco/Portfile 2007-07-21 20:37:30 UTC
(rev 27154)
+++ trunk/dports/python/py-psyco/Portfile 2007-07-22 04:00:51 UTC
(rev 27155)
@@ -5,7 +5,7 @@
namepy-psyco
version 1.5.2
-revision1
+revision2
categories python
platforms darwin
maintainers [EMAIL PROTECTED]
@@ -34,3 +34,5 @@
${destroot}${prefix}/share/doc/${name}
file copy ${worksrcpath}/doc ${destroot}${prefix}/share/
doc/${name}/
}
+
+platform darwin i386 {}
There was no need to upgrade the revision: if somebody already had it
installed, they were obviously already on a compatible architecture.
Nothing is gained from forcing them to rebuild it.
You may also wish to check for compatible architecture in a different
way. Your way currently handles only on Intel Mac OS X, but according
to the project's web site, it works on any OS so long as it's the _86
architecture. Consider doing it the way I've done it in the wine port:
http://trac.macosforge.org/projects/macports/browser/trunk/dports/x11/
wine/Portfile
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [27155] trunk/dports/python/py-psyco/Portfile
Ryan Schmidt wrote: You may also wish to check for compatible architecture in a different way. Your way currently handles only on Intel Mac OS X, but according to the project's web site, it works on any OS so long as it's the _86 architecture. Consider doing it the way I've done it in the wine port: http://trac.macosforge.org/projects/macports/browser/trunk/dports/x11/wine/Portfile I see no reason why checking for darwin i386 could be wrong. Do we really need to take care of other Operating Systems than Mac OS X? I mean, it's called MacPorts now and is targeted on users of Mac OS X. Who is using it on another system? And also see the wine port again, LDFLAGS like -framework won't work on other platforms... As platform is set to darwin, I think this is okay, but contrary to your statement above. Rainer ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [27155] trunk/dports/python/py-psyco/Portfile
On Jul 22, 2007, at 2:10 PM, Rainer Müller wrote: Do we really need to take care of other Operating Systems than Mac OS X? I mean, it's called MacPorts now and is targeted on users of Mac OS X. Who is using it on another system? We use MacPorts for a large software system that is Mac and Linux at the moment, and our group is considering using MacPorts for managing our Linux dependencies, as well. So we'd perhaps port MacPorts to Linux. And also see the wine port again, LDFLAGS like -framework won't work on other platforms... As platform is set to darwin, I think this is okay, but contrary to your statement above. Exactly what the platform tag is designed to do: we'd add platform linux stanzas to our ports, that would (of course) not have settings like -framework in them. Many (if not most) open-source packages already target linux successfully, so in most cases autoconf would determine the correct settings. I think. We haven't started a Linux port in earnest yet. Of course, I'm one of those nut jobs who tried to bring gentoo portage to Mac OS X about five years ago. Oy. - boyd Boyd Waters Scientific Programmer (no, really, that's what they call me) National Radio Astronomy Observatory Socorro, New Mexico ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: SoC: current status (Elias Pipping)
On Jul 22, 2007, at 9:35 AM, Elias Pipping wrote: merge.rb is a tool that's designed to merge an arbitrary amount of single-architecture directory-trees into a single universal tree. Sounds great. The code is made available under the MIT license.[3] Why choose an MIT license when the rest of the MacPorts tree is BSD licensed? The two licenses are functionally equivalent, but it's ideal to have unified licensing terms wherever possible. - Kevin ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [27155] trunk/dports/python/py-psyco/Portfile
[from the correct e-mail address, this time] On Jul 22, 2007, at 1:10 PM, Rainer Müller wrote: Ryan Schmidt wrote: You may also wish to check for compatible architecture in a different way. Your way currently handles only on Intel Mac OS X, but according to the project's web site, it works on any OS so long as it's the _86 architecture. Consider doing it the way I've done it in the wine port: http://trac.macosforge.org/projects/macports/browser/trunk/dports/ x11/wine/Portfile I see no reason why checking for darwin i386 could be wrong. Do we really need to take care of other Operating Systems than Mac OS X? I mean, it's called MacPorts now and is targeted on users of Mac OS X. Who is using it on another system? That's no reason to -intentionally- box yourself (or others) into a corner. The requirement is for 'x86', not for darwin, and as such, expressing a much broader dependency is incorrect. -landonf PGP.sig Description: This is a digitally signed message part ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
