On Sunday June 05 2016 17:00:17 Gustaf Neumann wrote:
> i was talking about a general mechanism, through which a port maintainer
> can change the behavior of commands on which others depend. I do not see
> much danger with extending the platform command as discussed.
Of course.
understanding of the
consequences of such changes to other ports. This would make maintenance
even more difficult.
What effect could the addition of an "else" condition to the platform statement
have on other ports, whether it's provided through a PortGroup (or similar) or through
base
nces of such changes to other ports. This would make maintenance
>even more difficult.
What effect could the addition of an "else" condition to the platform statement
have on other ports, whether it's provided through a PortGroup (or similar) or
through base? If it's done thro
the posted patch.
In case such a modification to platform does get incorporated in a future
MacPorts version, would there be a way to to allow port authors to use the new
syntax immediately, before that future version is released? It seems that this
kind of simple patches to base can be distr
or do I file one just for the
platform{} mod?
In case such a modification to platform does get incorporated in a future
MacPorts version, would there be a way to to allow port authors to use the new
syntax immediately, before that future version is released? It seems that this
kind of simple
Gustaf Neumann wrote:
> The original code used as signature "proc platform {args} ..." and
> pulled later the "os" out of $args, whereas the posted one uses "proc
> platform {os args}",
Ah, right. Missed that :-/
> called, then the variant with &q
Am 04.06.16 um 10:08 schrieb René J. V. Bertin:
if {$len < 1} {
My code has 2 here, and I think that's reasonable ("platform darwin" on its own
doesn't make a lot of sense).
The original code used as signature "proc platform {args} ..." and
pulled later t
Gustaf Neumann wrote:
> The code below is more in line with current tcl code practice
Seems to work too
> (untested, using e.g. tcl index expressions).
after correcting a few omissions ;)
> if {$len < 1} {
My code has 2 here, and I think that's reasonable ("platf
Am 03.06.16 um 14:55 schrieb René J. V. Bertin:
Rainer Müller wrote:
The definition of the platform proc is here:
https://trac.macports.org/browser/trunk/base/src/port1.0/portutil.tcl?rev=149111#L765
Extending that syntax with an optional code block after an "else"
keywor
Rainer Müller wrote:
> The definition of the platform proc is here:
>
>
https://trac.macports.org/browser/trunk/base/src/port1.0/portutil.tcl?rev=149111#L765
>
> Extending that syntax with an optional code block after an "else"
> keyword would be possible.
On
On Tuesday May 31 2016 09:31:02 Brandon Allbery wrote:
> On Tue, May 31, 2016 at 4:24 AM, René J.V. wrote:
> Is there some reason you can't invert the logic?
I don't see how, not if you have things to be done on one platform and other
things to be done on another. That'
On Tue, May 31, 2016 at 4:24 AM, René J.V. wrote:
> That's a pity. I had quite a few if {${os.platform} eq "darwin"} {} else
> {} statements in certain of my ports, which I most all replaced with
> platform statements at the suggestion to do so.
Is there some reason yo
On 2016-05-31 10:24, René J.V. Bertin wrote:
> Would it be hard (and potentially acceptable) to extend the syntax to
>
> platform ... {
> } else {
> }
>
> of something of the sort? That seems like it might require patching the Tcl
> source code.
The definition of t
On Sunday May 29 2016 10:14:53 Ryan Schmidt wrote:
>Correct, you can't use a platform statement to do that, so use an if
>statement.
That's a pity. I had quite a few if {${os.platform} eq "darwin"} {} else {}
statements in certain of my ports, which I most
On May 29, 2016, at 05:07, René J.V. Bertin wrote:
>
> The documentation states that the platform{} syntax for specifying platform
> variants doesn't allow you to specify a range of platforms. That still seems
> to be accurate.
Correct, except that the term "platform
Hi,
The documentation states that the platform{} syntax for specifying platform
variants doesn't allow you to specify a range of platforms. That still seems to
be accurate.
So there is no way to use a single platform statement to replace `if
{${os.platform} ne "darwin"}` (I
any of Apple's proprietary bits. Whereas 'macosx' is
>> what most of us use, OS X. Darwin in this context is the union of
>> puredarwin and macosx (i.e. in 'platforms' it means the port will work
>> on both of them, and in 'platform' statements t
nux for server-side tasks, almost none
of the ports work there and it is completely unsupported. Additionally,
puredarwin is dead, so there's not point in considering it either.
We often use a platform darwin {} block when adding conditional code depending
on a version of OS X, but that's mos
'macosx' labels? The guide is not
>> very illuminating on this point.
>
> Puredarwin is an OS based on Apple's open source Darwin releases and
> doesn't include any of Apple's proprietary bits. Whereas 'macosx' is
> what most of us use,
uredarwin is an OS based on Apple's open source Darwin releases and
doesn't include any of Apple's proprietary bits. Whereas 'macosx' is
what most of us use, OS X. Darwin in this context is the union of
puredarwin and macosx (i.e. in 'platforms' it means the port wi
Hi all,
Can someone explain what the meaning of the possible values of the
'platforms' variable are in a Portfile? Most ports seem to list 'darwin'
but I have seen some that say 'macosx' or even 'puredarwin'. I understand
the meaning of clearly different operating system designations such as
freeb
ul addition, too.
Come to think of it, MS Windows doesn't have fork() AFAIK. How has that been
dealt with?
NB: if a wrapper class or helper function is feasible, it should also be
possible to begin developing it in a portable way on the platform we currently
have, i.e. KDE4 (evidently not nece
Ian,
I took a look at kdelibs4 in macports and
https://trac.macports.org/browser/trunk/dports/kde/kdelibs4/files/workaround-kdeinit4-crash.patch
looks particularly interesting to what we are trying to fix here.
Especially it's use of a separate executable (helperExe) to launch
klauncher with. If y
On 12/02/2015, at 10:34 AM, Brandon Allbery wrote:
> On Wed, Feb 11, 2015 at 6:31 PM, René J.V. wrote:
> I take that to mean that doing fork() doesn't oblige you to do an exec()
> afterwards, it's that you cannot do a fork() from a process that's not been
> started through exec.
>
> I will gues
On 2015-2-12 10:31 , René J.V. Bertin wrote:
> On Wednesday February 11 2015 16:02:49 Jeremy Whiting wrote:
>
> Hi Jeremy,
>
> CC'ing this to macports-dev as there may be someone there who can give some
> background and a proper solution.
>
>> In Console.app I see this error:
>> 2/11/15 3:53:53
On Wed, Feb 11, 2015 at 6:31 PM, René J.V. wrote:
> I take that to mean that doing fork() doesn't oblige you to do an exec()
> afterwards, it's that you cannot do a fork() from a process that's not been
> started through exec.
I will guess that this is related to the fact that such processes ar
On Wed, Feb 11, 2015 at 4:31 PM, René J.V. wrote:
> On Wednesday February 11 2015 16:02:49 Jeremy Whiting wrote:
>
> Hi Jeremy,
>
> CC'ing this to macports-dev as there may be someone there who can give
> some background and a proper solution.
>
> > In Console.app I see this error:
> > 2/11/15 3:
On Wednesday February 11 2015 16:02:49 Jeremy Whiting wrote:
Hi Jeremy,
CC'ing this to macports-dev as there may be someone there who can give some
background and a proper solution.
> In Console.app I see this error:
> 2/11/15 3:53:53.155 PM kdeinit5: klauncher --fd=8[60704]: Process 60703 was
On Mon, Dec 24, 2012 at 04:18:47PM +1100, Andy Kitchen wrote:
> I'm a new committer, so, Hi everyone.
Hi and welcome to the MacPorts project! :)
> Wrt. The Haskell platform, it's a priority for me to get the macports
> Haskell platform up-to-date and have an easy way to k
Hi All,
I'm a new committer, so, Hi everyone. I'm a 23 y/o Australian, I just
graduated with a Computer Science Degree this year and I'm going
back for honours next year. My interests are functional programming
(Haskell, Clojure, Scheme) and numerical analysis.
Wrt. The Haskell p
> Installer packages produced with "port pkg" are designed only for use on the
> version of OS X they were created on.
>
> In my opinion you'd have the greatest success of creating a package
> compatible with 10.6 and up by running the "port pkg" command on a computer
> running 10.6.
>
> If th
> On Sep 22, 2012, at 6:17 AM, Ryan Schmidt wrote:
>> On Sep 22, 2012, at 05:04, Joshua Root wrote:
>> However, testing for
>> these is officially frowned upon. Whenever possible, upstream should
>> really test for specific ways in which platforms are known to differ
>> (presence of particular hea
On Sep 22, 2012, at 05:04, Joshua Root wrote:
> On 2012-9-22 19:51 , Ryan Schmidt wrote:
>> The system headers use availability macros, and at least on Mountain Lion
>> their definitions include the word "macosx", e.g.
>> "availability(macosx,introduced=10.5)". The problem occurs when a softwar
On 2012-9-22 19:51 , Ryan Schmidt wrote:
> The system headers use availability macros, and at least on Mountain Lion
> their definitions include the word "macosx", e.g.
> "availability(macosx,introduced=10.5)". The problem occurs when a software
> package defines its own preprocessor symbol call
I want to alert port maintainers to a strange error message users might report
starting on Mountain Lion:
/usr/include/sys/stat.h:451:40: error: expected a platform name, e.g., 'macosx'
int lchflags(const char *, __uint32_t) __OSX_AVAILABLE_STARTING(__MAC_10_5,
__
On 2009-05-23 09:08, Ryan Schmidt wrote:
> On May 21, 2009, at 12:29, David Evans wrote:
>> Also I'm not sure why you made it a path dependency. Should this
>> be done globally?
>
> I am getting tired of having to monitor ports' dependencies for
> things like "port:pango" and "port:cairo" and
On May 21, 2009, at 12:29, David Evans wrote:
ryandes...@macports.org wrote:
--- trunk/dports/gnome/gnome-platform-suite/Portfile 2009-05-09
20:16:23 UTC (rev 50796)
+++ trunk/dports/gnome/gnome-platform-suite/Portfile 2009-05-09
20:40:52 UTC (rev 50797)
@@ -18,6 +18,7 @@
homepage
ryandes...@macports.org wrote:
Revision
50797 <http://trac.macports.org/changeset/50797>
Author
ryandes...@macports.org
Date
2009-05-09 13:40:52 -0700 (Sat, 09 May 2009)
Log Message
gnome-platform-suite:
* allow pango-devel to satisfy pango dependency
* pkgconfi
Hi,
> It seems like having to know this stuff a priori would partly defeat the
> purpose of having iconv? According to the iconv_open man page, you can
> pass "wchar_t" as tocode or fromcode and it will be interpreted as
> defined by the machine, OS and current locale.
>
> - Josh
Wow, that was e
David Bruce wrote:
> Hi,
>
> I'm the upstream maintainer for Tux Math and Tux Typing. I just
> contributed a current portfile for tuxmath, and would like to add
> tuxtype as well. The tuxtype port is almost ready to go, but a
> significan part of the game doesn't work because the existing code t
e that in the long run it is better to get away from wchar_t,
and that it is generally better to test directly for features a la
Autoconf rather than just checking for a platform symbol. But if
anyone knows these details offhand, I could have a functioning tuxtype
port tonight.
Thanks for any h
On Jan 24, 2008, at 9:35 PM, Ryan Schmidt wrote:
That makes good sense to me, especially after looking at the
ghc Portfile.
The gsl port seems to think this functionality already exists:
platform darwin 6 7 {
configure.cflags-append "-O1"
}
I wonder whether this section act
On 25.01.2008, at 06:35, Ryan Schmidt wrote:
platform darwin 6 7 {
configure.cflags-append "-O1"
}
I wonder whether this section actually gets used on Panther or
Jaguar...
Me too! [1]
This bit was in the Portfile when I took maintainership, I do not have
any of the releva
On Jan 24, 2008, at 15:52, Eric Hall wrote:
On Sat, Jan 19, 2008 at 04:17:53PM -0800, Jordan K. Hubbard wrote:
I was just looking at the ghc port a few days ago, mostly in an
attempt to figure out why it a-splode! on my 10.5 PPC system, and I
noticed a lot of this:
platform darwin 7 powerpc
On Sat, Jan 19, 2008 at 04:17:53PM -0800, Jordan K. Hubbard wrote:
> Hey all,
>
> I was just looking at the ghc port a few days ago, mostly in an
> attempt to figure out why it a-splode! on my 10.5 PPC system, and I
> noticed a lot of this:
>
> platform darwin 7 power
Hey all,
I was just looking at the ghc port a few days ago, mostly in an
attempt to figure out why it a-splode! on my 10.5 PPC system, and I
noticed a lot of this:
platform darwin 7 powerpc { ... }
platform darwin 8 powerpc { ... }
platform darwin 8 i386 { ... }
And so on. It occurred to
On Dec 24, 2007, at 8:13 PM, Ryan Schmidt wrote:
These lines in a portfile are useless now, right?
platform darwin 8 {
configure.compiler gcc-4.0
}
Ever since default compilers were set in MacPorts base, gcc-4.0 is
the default compiler on darwin 8 anyway, so we can remove these
These lines in a portfile are useless now, right?
platform darwin 8 {
configure.compiler gcc-4.0
}
Ever since default compilers were set in MacPorts base, gcc-4.0 is
the default compiler on darwin 8 anyway, so we can remove these lines
from all portfiles, right? I'm happy 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
f 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
On Jul 15, 2007, at 15:21, Anders F Björklund wrote:
Ryan Schmidt wrote:
And you posited that "x86" worked on some platforms, while I know
that "i386" is correct for Intel Macs. In terms of what happens if
you write a platform selector in MacPorts, I don't think
Ryan Schmidt wrote:
And you posited that "x86" worked on some platforms, while I know that
"i386" is correct for Intel Macs. In terms of what happens if you
write a platform selector in MacPorts, I don't think i386 is a subset
of x86 at all; if I were to draw a Venn d
.
Am I far off ?
On Jul 11, 2007, at 00:26, Yves de Champlain wrote:
I just saw "platform intel" Does that really work ?
I really have no idea about "x86" or "platform intel". Where is
the code in base that autoselects platforms? We could look there
to see
Champlain wrote:
I just saw "platform intel" Does that really work ?
I really have no idea about "x86" or "platform intel". Where is
the code in base that autoselects platforms? We could look there
to see what it supports.
it fetches uname, so whatever comes ou
On Jul 15, 2007, at 10:03, Yves de Champlain wrote:
Mmm i386 is for intel, sure. But x86 targets a wider set of
platforms (intel and AMD). So I always saw i386 as a subset of x86.
Am I far off ?
On Jul 11, 2007, at 00:26, Yves de Champlain wrote:
I just saw "platform intel"
Le 07-07-15 à 00:04, Ryan Schmidt a écrit :
On Jul 10, 2007, at 23:49, Yves de Champlain wrote:
Le 07-07-11 à 00:25, Ryan Schmidt a écrit :
As for "variant x86", the correct syntax would be "platform
i386", wouldn't it? I don't see any ports with "platfo
On Jul 10, 2007, at 23:49, Yves de Champlain wrote:
Le 07-07-11 à 00:25, Ryan Schmidt a écrit :
As for "variant x86", the correct syntax would be "platform i386",
wouldn't it? I don't see any ports with "platform x86", and nobody
with an Intel
Randall Wood wrote:
You could try this:
variant aqua conflicts x11 requires macosx {}
variant x11 conflicts aqua {}
Here is what I ended up with:
default_variants +aqua
platform macosx {}
variant aqua requires macosx description "Use the wxMac port of
wxWidgets" {
d
On 12 Jul 2007, at 08:14, Anders F Björklund wrote:
Is it possible to set "default_variants" per platform ?
Basically, I want to set +aqua for platform macosx,
and +x11 for platform puredarwin or platform freebsd.
I tried the most straight-forward approach, wrapping
default_v
Ryan Schmidt wrote:
I tried the most straight-forward approach, wrapping
default_variants in platform, but it didn't work...
It should be possible. Off the top of my head:
platform macosx {
default_variants +aqua
}
platform puredarwin {
default_variants +x11
}
This wa
On Jul 12, 2007, at 07:14, Anders F Björklund wrote:
Is it possible to set "default_variants" per platform ?
Basically, I want to set +aqua for platform macosx,
and +x11 for platform puredarwin or platform freebsd.
I tried the most straight-forward approach, wrapping
default_v
Is it possible to set "default_variants" per platform ?
Basically, I want to set +aqua for platform macosx,
and +x11 for platform puredarwin or platform freebsd.
I tried the most straight-forward approach, wrapping
default_variants in platform, but it didn't work...
For now
t x86
Don't forget 2 ports that use "variant macosx". Oops, one of those
is mine...
Now, that should be "platform", shouldn't it ?
Should I go on and change everything ?
All except "variant x86", probably yes...
As for "variant x86", the co
t x86
Don't forget 2 ports that use "variant macosx". Oops, one of those
is mine...
Now, that should be "platform", shouldn't it ?
Should I go on and change everything ?
All except "variant x86", probably yes...
As for "variant x86", the co
;variant macosx". Oops, one of those is
mine...
Now, that should be "platform", shouldn't it ?
Should I go on and change everything ?
All except "variant x86", probably yes...
As for "variant x86", the correct syntax would be "platform i386",
w
Hi
I'm in a normalizing mood.
I found out that
87 ports use variant darwin
10 ports use variant puredarwin
10 ports use variant freebsd
3 ports use variant powerpc
3 ports use variant x86
Now, that should be "platform", shouldn't it ?
Should I go on and chang
of the code was for remote fetching, either inside
of MacPorts with the proposed patches or outside of MacPorts using
some kind of Package Manager like for instance Yum/APT-RPM/Smart...
And with r26693 and ${os.major} in sight, don't we have more
flexibility now to check for the major p
stead referring to
"archivemode"?
And with r26693 and ${os.major} in sight, don't we have more
flexibility now to check for the major platform number we're
interested in? From what I understand, r26693 just records $
{os.major} (e.g. Darwin *8*)... but we're not y
So we might need to include at least the major version in
the paths used, so that they will become something like:
darwin/9/i386/
darwin/9/ppc/
darwin/8/i386/
darwin/8/ppc/
darwin/7/ppc/
freebsd/7/i386/
freebsd/6/i386/
freebsd/5/i386/
...
There is now an ${os.major} variable that can be used fo
There is a upcoming problem that will occur with the binary
archives/packages, in that most of the code currently only
checks for ${os.platform} and ${os.arch} when looking for
binaries, ignoring ${os.version} which might be important ?
e.g. Panther and Tiger will try to use the same binaries
and
On May 25, 2007, at 16:44, Ryan Schmidt wrote:
sysutils/sockstat does this:
platform darwin 8 {
ui_error " ATTENTION "
ui_error "Sockstat is not working under darwin 8 nor tiger. Please
use"
ui_error "lsof -i6/lsof -i4/lsof -U i
Le 26 mai 07 à 00:14, Ryan Schmidt a écrit :
On May 25, 2007, at 16:49, N_Ox wrote:
Le 25 mai 07 à 23:44, Ryan Schmidt a écrit :
platform darwin 8 {}
pre-fetch {
if { [variant_isset darwin_8] } {
ui_error " ATTENTION "
ui_error "Sockstat
On May 25, 2007, at 17:14, Ryan Schmidt wrote:
On May 25, 2007, at 16:49, N_Ox wrote:
Le 25 mai 07 à 23:44, Ryan Schmidt a écrit :
platform darwin 8 {}
pre-fetch {
if { [variant_isset darwin_8] } {
ui_error " ATTENTION "
ui_error "
On May 25, 2007, at 16:49, N_Ox wrote:
Le 25 mai 07 à 23:44, Ryan Schmidt a écrit :
platform darwin 8 {}
pre-fetch {
if { [variant_isset darwin_8] } {
ui_error " ATTENTION "
ui_error "Sockstat is not working under darwin 8 nor tige
Hello,
there's just something bothering me with platform/variant directives
i've seen here and there.
Why do you use a dummy platform and use variant_isset in the stage
directive?
From what i've seen (and coded, of course), every stage in every
activated variant/platf
TED]
sysutils/sockstat does this:
platform darwin 8 {
ui_error " ATTENTION "
ui_error "Sockstat is not working under darwin 8 nor tiger. Please use"
ui_error "lsof -i6/lsof -i4/lsof -U instead."
ui_error " ATTENTION!
Hi,
$port cat all | grep -c "platform universal"
1
$port cat all | grep -c "variant universal"
5
so that's only curl right now. I heard the call for
universal binaries the other day and started looking
for ports that could easily be built as such
So I said earlier [1] that I had seen a port with a variant
+universal, which is a strategy which seems now to have been adopted
by some other ports. However, I just noticed that the port where I
thought I had seen that, curl, actually says "platform universal"
instead o
78 matches
Mail list logo
