Re: Make options lists instead of strings and make -append more magical
On 2013-10-08 21:07, Ryan Schmidt wrote:
Options like configure.args or depends_lib seem in a way magical
because of the convenience methods MacPorts makes available, but
they're not as magical as they could be.
We use commands like configure.args-append to add to options, and
this makes us feel like options are lists or arrays, but in fact,
they're just strings. The implementation of handle_option-append is
quite simple: it just uses Tcl's built-in concat procedure, which
trims leading and trailing whitespace and combines items with a
single space. This has undesirable consequences when the option in
question needs a different type of concatenation.
Depending on the arguments appended, they might be plain string or they
might be lists. I remember we once had problems with {} and in
descriptions due to this...
For example, consider configure.pkg_config_path. Using
configure.pkg_config_path-append foo will append a space and foo
to configure.pkg_config_path, but in fact, pkg_config_path needs to
be colon-separated, not space-separated. So it becomes incumbent upon
each maintainer to remember that and to never use
configure.pkg_config_path-append, and rather to manually concatenate
onto it using a colon. I'd rather not make maintainers have to
remember that kind of detail.
I totally agree with this that options should have different semantics.
Clemens already started working on something similar in his base-rewrite
branch by making a difference between a list and a set. For example, the
depends_* options should be treated as sets as it does not make sense to
add the same dependency multiple times. Something like configure.args
should be a list, as the order of arguments can be important or may
contain the same item multiple times.
I guess this commit is best to describe these changes.
https://trac.macports.org/changeset/103064
(Side note: I don't like the overly complex -listsemantics and
-setsemantics modifiers, -list and -set should be enough.)
Adding custom separators for options sounds like another good idea.
However, we would also need to define if and how this separator should
be escaped if it is passed literally.
Or, consider notes. Notes are supposed to be paragraphs of text. A
port might define a paragraph or two of notes, then want to provide
additional notes conditionally, perhaps in a variant. We tend to want
to separate paragraphs of text by two newlines. But if a port uses
notes-append foo then only a single space and foo will be
appended to the existing notes. There's no way around this: even
something like notes-append \n\nfoo doesn't work because concat
trims the leading whitespace.
Actually, it works for notes because I added special handling for this
case with handle_option_string. It's special because the leading
whitespace of the first line is stripped from all lines. This allows to
indent the notes without indenting the output.
notes {
Foo
}
notes-append {
Bar
}
notes-append \n\nBaz
This example should work fine and produce the expected output.
However, I noticed there is an edge case where it does not work as you
would expected. That is when the first line is left empty (even no
whitespace):
notes-append {
Qux
}
This can be fixed by either adding whitespace to indent the empty line,
or add a single notes-append \n beforehand.
I wonder how feasible it would be to treat options as lists instead
of strings, and then teach MacPorts to use different concatenation
values depending on which option it is. notes could be concat'd with
\n\n, configure.pkg_config_path could be concat'd with :, if we
had a configure.path it could be concat'd with :, and could be
used for others.
I would say such changes demand an increase of the PortSystem version as
it changes the way options are used. This is not a problem as MacPorts
was designed to support multiple different versions of the port system
and every existing Portfile would still work. Furthermore, it would also
remove the need to design this change in a backwards compatible way.
Trying to include options within a portfile has also been
problematic. For example sometimes I seem to have to use join or eval
to get things to work without Tcl inserting incorrect escaping. Would
be lovely if we could make this process more transparent and
straightforward. For example, perhaps the hypothetical base procedure
that would perform this concatenation could be exported for portfiles
to use when needed.
This depends a lot on where we would do the substitution of the
separator. Either we do it right on -append, but that might make it
harder to -delete the value the same way. The other possibility would be
to do it only if the option is read using the variable ${foo}. Raw
access would still be possible for the port system internally.
Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
Re: xinstall vs file copy/mkdir
On Oct 7, 2013, at 11:31 AM, Ryan Schmidt ryandes...@macports.org wrote: On Oct 7, 2013, at 07:16, Davide Liessi davide.lie...@gmail.com wrote: Is there a preferred choice between xinstall and file Tcl extensions? Which one should I use? For creating directories, they're pretty equivalent. If you need to specify ownership (which some ports like servers need) or permissions (which you almost never need for directories) xinstall is more convenient because it lets you do it all at once. Otherwise my rule of thumb is usually to use xinstall at destroot time and file mkdir otherwise. For copying files, same rule of thumb. Also, file copy preserves modification times; xinstall touches the file so you get the current time. And xinstall has the convenient -W flag that lets you copy multiple files from a single directory without having to name that directory over and over. All things equal, I generally prefer xinstall because it automatically produces a debug message while file copy does not. It makes reviewing main.log somewhat easier. (Obviously nothing prevents me from using explicitly using ui_debug, but I'd rather not.) vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
variant requires odd functionality
I just pushed the new port for ticket #39327
https://trac.macports.org/ticket/39327 , revision r112010
https://trac.macports.org/changeset/112010 ; it installs both static
and dynamic libraries, and works with +universal to boot!
In my testing I came upon something interesting with the way port
handles requires in variants; here's the comment I added to the Portfile
for itsol, augmented to make sense outside the Portfile's context:
{{{
atlas does not provide a +g95 variant, so if +g95 is used, +accelerate
must also be used. +accelerate will work with +gccXY, so this is all a
bit complex to check for; normally I would set the +g95 variant to
requires accelerate. But, setting this 'requires' does not yet seem
to work with 'port' to get [+]accelerate as the default variant; leaving
it out does work, so doing that and checking for this condition later,
for now. To be clear, port handles the requires correctly internally,
but not from the user's perspective -- for example, specifying sudo
port install itsol -accelerate +g95 will result in +accelerate
implicitly being used, overriding the user's request but without
notifying the user. Removing the 'requires' and putting in a manual
check works just fine for now.
}}}
I'm not sure if the above behavior is a feature or bug. My fix is
simple, but I'd think this would be better handled within port itself. -
MLD
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [112012] trunk/dports/python/py-gobject3/Portfile
Hi, On Wed, Oct 09, 2013 at 09:08:59AM -0700, dev...@macports.org wrote: Revision: 112012 https://trac.macports.org/changeset/112012 Author: dev...@macports.org Date: 2013-10-09 09:08:59 -0700 (Wed, 09 Oct 2013) Log Message: --- py-gobject3: update to version 3.10.0. Since this apparently broke py26-gobject3 we should probably remove that from the Portfile. I haven't checked exactly what's wrong with the py26-gobject3 build, though. -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [112012] trunk/dports/python/py-gobject3/Portfile
or just do that thing that some python ports do where older python versions have separately-written sub-ports for the last version of that subport that worked with that python version. On Wed, Oct 9, 2013 at 12:32 PM, Clemens Lang c...@macports.org wrote: Hi, On Wed, Oct 09, 2013 at 09:08:59AM -0700, dev...@macports.org wrote: Revision: 112012 https://trac.macports.org/changeset/112012 Author: dev...@macports.org Date: 2013-10-09 09:08:59 -0700 (Wed, 09 Oct 2013) Log Message: --- py-gobject3: update to version 3.10.0. Since this apparently broke py26-gobject3 we should probably remove that from the Portfile. I haven't checked exactly what's wrong with the py26-gobject3 build, though. -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [112012] trunk/dports/python/py-gobject3/Portfile
On 10/9/13 9:32 AM, Clemens Lang wrote: Hi, On Wed, Oct 09, 2013 at 09:08:59AM -0700, dev...@macports.org wrote: Revision: 112012 https://trac.macports.org/changeset/112012 Author: dev...@macports.org Date: 2013-10-09 09:08:59 -0700 (Wed, 09 Oct 2013) Log Message: --- py-gobject3: update to version 3.10.0. Since this apparently broke py26-gobject3 we should probably remove that from the Portfile. I haven't checked exactly what's wrong with the py26-gobject3 build, though. Removed in r112013. Support for python 2.6 has been removed upstream. See https://git.gnome.org/browse/pygobject/commit/?h=pygobject-3-10id=89d05f91cee419d46cb5318d4a9001ec315a3475 for the rationale. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [112008] trunk/dports/gis/sfcgal/Portfile
On Oct 9, 2013, at 06:37, vi...@macports.org wrote:
Revision: 112008
https://trac.macports.org/changeset/112008
Author: vi...@macports.org
Date: 2013-10-09 04:37:14 -0700 (Wed, 09 Oct 2013)
Log Message:
---
Corrects a reinplace that is only pertinent for the +viewer variant
Modified Paths:
--
trunk/dports/gis/sfcgal/Portfile
Property Changed:
trunk/dports/gis/sfcgal/Portfile
Modified: trunk/dports/gis/sfcgal/Portfile
===
--- trunk/dports/gis/sfcgal/Portfile 2013-10-09 11:34:08 UTC (rev 112007)
+++ trunk/dports/gis/sfcgal/Portfile 2013-10-09 11:37:14 UTC (rev 112008)
@@ -1,5 +1,5 @@
# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil;
c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
-# $Id: Portfile 111992 2013-10-08 19:34:50Z vi...@macports.org $
+# $Id$
PortSystem 1.0
PortGroup cmake 1.0
@@ -53,8 +53,10 @@
}
post-configure {
-reinplace -E s|(.*)|\\1 -F /opt/local/Library/Frameworks -lQtCore
-lQtOpenGL -lQtGui| \
-${worksrcpath}/viewer/CMakeFiles/viewer-SFCGAL.dir/link.txt
+if {[variant_isset viewer]} {
+reinplace -E s|(.*)|\\1 -F /opt/local/Library/Frameworks -lQtCore
-lQtOpenGL -lQtGui| \
+${worksrcpath}/viewer/CMakeFiles/viewer-SFCGAL.dir/link.txt
+}
Doesn't this need to say ${frameworks_dir} instead of
/opt/local/Library/Frameworks?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [112006] trunk/dports/gis
On Oct 9, 2013, at 06:23, vi...@macports.org wrote:
Revision: 112006
https://trac.macports.org/changeset/112006
Author: vi...@macports.org
Date: 2013-10-09 04:23:00 -0700 (Wed, 09 Oct 2013)
Log Message:
---
Initial commit
Added Paths:
---
trunk/dports/gis/sfcgal/
trunk/dports/gis/sfcgal/Portfile
+license GPL
Which version(s) of GPL?
+use_parallel_build no
+use_parallel_build yes
Which is it? :)
+master_siteshttps://github.com/Oslandia/SFCGAL/archive
+distnamev${version}
Consider using the github portgroup.
+destroot.target install
That's the default.
+post-destroot {
+system -W ${destroot}/${prefix}/include rm -rf CGAL
${prefix} begins with a slash; you shouldn't put another slash before it. Also,
no need to use system to delete; just use the MacPorts delete procedure:
post-destroot {
delete ${destroot}${prefix}/include/CGAL
}
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [112002] trunk/dports/net/junkbuster/Portfile
On Oct 8, 2013, at 22:07, j...@macports.org wrote: Revision: 112002 https://trac.macports.org/changeset/112002 Author: j...@macports.org Date: 2013-10-08 20:07:06 -0700 (Tue, 08 Oct 2013) Log Message: --- junkbuster: remove dependency on deleted apple-gcc33 port, simplify compiler selection Modified Paths: -- trunk/dports/net/junkbuster/Portfile Too bad the port was deleted since this port requires it to build on Intel. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [112002] trunk/dports/net/junkbuster/Portfile
On 2013-10-09 20:22, Ryan Schmidt wrote: On Oct 8, 2013, at 22:07, j...@macports.org wrote: Revision: 112002 https://trac.macports.org/changeset/112002 Author: j...@macports.org Date: 2013-10-08 20:07:06 -0700 (Tue, 08 Oct 2013) Log Message: --- junkbuster: remove dependency on deleted apple-gcc33 port, simplify compiler selection Modified Paths: -- trunk/dports/net/junkbuster/Portfile Too bad the port was deleted since this port requires it to build on Intel. This software was not updated for more than 11 years [1]. I doubt it serves a real purpose anymore and would vote to just remove the non-working port. Rainer [1] http://f2.org/products/ijb-zlib/#Version ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [112006] trunk/dports/gis
Ryan, Revision: 112006 […] Thanks for you ongoing alertness. I’ve taken into account all but one of your remarks: I couldn’t tweak the github port to fit that obviously non-standand repository, so I just left the master_site and all other variables as is. Thanks once more. Vincent ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
contributing to macports
Hello, I have a custom ports tree that I've been actively maintaining and using for myself: https://github.com/1st1/ports-overlay If it's possible, I'd like to contribute some of it to the main line, particularly: - nginx +lua variant - postgresql database with 'contrib/hstore' option (this is a very trivial patch to the original port) - cassandra database - riak database - everything else worth interest (lots of python packages for instance) Please advise me what the next steps might be. Thank you, Yury Selivanov ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: contributing to macports
On Oct 9, 2013, at 12:25 PM, Yury Selivanov wrote: Hello, I have a custom ports tree that I've been actively maintaining and using for myself: https://github.com/1st1/ports-overlay If it's possible, I'd like to contribute some of it to the main line, particularly: - nginx +lua variant - postgresql database with 'contrib/hstore' option (this is a very trivial patch to the original port) - cassandra database - riak database - everything else worth interest (lots of python packages for instance) Please advise me what the next steps might be. For changes to existing ports create unified diff patchfiles [1] and open a trac enhancement ticket [2]; remembering to cc the maintainer if there is one. For new ports open a trac submission ticket. [1] http://guide.macports.org/#development.patches.portfile [2] http://guide.macports.org/#project.tickets.creating Regards, Bradley Giesbrecht (pixilla) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [112002] trunk/dports/net/junkbuster/Portfile
On 2013-10-10 05:22 , Ryan Schmidt wrote: On Oct 8, 2013, at 22:07, j...@macports.org wrote: Revision: 112002 https://trac.macports.org/changeset/112002 Author: j...@macports.org Date: 2013-10-08 20:07:06 -0700 (Tue, 08 Oct 2013) Log Message: --- junkbuster: remove dependency on deleted apple-gcc33 port, simplify compiler selection Modified Paths: -- trunk/dports/net/junkbuster/Portfile Too bad the port was deleted since this port requires it to build on Intel. I don't think apple-gcc33 built on anything remotely recent either. There's a reason every single more recent compiler rejects the code in junkbuster; some of it is totally invalid. If we're going to keep this port then the code needs to be fixed. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
[112024] trunk/dports/net/libproxy/Portfile
Revision: 112024 https://trac.macports.org/changeset/112024 Author: devans at macports.org Date: 2013-10-09 15:59:21 -0700 (Wed, 09 Oct 2013) Log Message: --- libproxy: depend on perl5.12 rather than perl5 stub. Modified Paths: -- trunk/dports/net/libproxy/Portfile Modified: trunk/dports/net/libproxy/Portfile === --- trunk/dports/net/libproxy/Portfile2013-10-09 22:55:42 UTC (rev 112023) +++ trunk/dports/net/libproxy/Portfile2013-10-09 22:59:21 UTC (rev 112024) @@ -7,6 +7,7 @@ namelibproxy version 0.4.11 epoch 1 +revision1 license LGPL-2.1 categories net maintainers devans openmaintainer @@ -32,7 +33,7 @@ port:pkgconfig depends_lib port:gconf \ -port:perl5 +port:perl5.12 perl5 isn't exactly a stub, it installs symlinks to executables including 'perl'. This change is only correct if libproxy runs 'perl5.12' and not just 'perl'. It may now be finding the system perl rather than the MacPorts perl when the perl5 port is not installed. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
[112016] trunk/dports/gis/sfcgal/Portfile
Revision: 112016 https://trac.macports.org/changeset/112016 Author: vince at macports.org Date: 2013-10-09 11:55:31 -0700 (Wed, 09 Oct 2013) Log Message: --- Take into account various remarks of Ryan Modified Paths: -- trunk/dports/gis/sfcgal/Portfile Modified: trunk/dports/gis/sfcgal/Portfile === --- trunk/dports/gis/sfcgal/Portfile 2013-10-09 18:13:39 UTC (rev 112015) +++ trunk/dports/gis/sfcgal/Portfile 2013-10-09 18:55:31 UTC (rev 112016) @@ -17,9 +17,8 @@ intersections, buffering, etc.). platforms darwin -license GPL +license LGPL 2 This appears to be incorrect in two ways. 1. The license should be GPL-3+ (only a few files are LGPL-3+ and none are LGPL-2) 2. ./portmgr/jobs/port_binary_distributable.tcl -v sfcgal sfcgal is not distributable because its license 2 is not known to be distributable The license name and version need to be separated by a dash. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [112002] trunk/dports/net/junkbuster/Portfile
On Oct 9, 2013, at 19:49, Joshua Root j...@macports.org wrote: On 2013-10-10 05:22 , Ryan Schmidt wrote: On Oct 8, 2013, at 22:07, j...@macports.org wrote: Revision: 112002 https://trac.macports.org/changeset/112002 Author: j...@macports.org Date: 2013-10-08 20:07:06 -0700 (Tue, 08 Oct 2013) Log Message: --- junkbuster: remove dependency on deleted apple-gcc33 port, simplify compiler selection Modified Paths: -- trunk/dports/net/junkbuster/Portfile Too bad the port was deleted since this port requires it to build on Intel. I don't think apple-gcc33 built on anything remotely recent either. There's a reason every single more recent compiler rejects the code in junkbuster; some of it is totally invalid. If we're going to keep this port then the code needs to be fixed. Yes that's a better way to put it. I found a patch for this in FreeBSD ports which seemed to work. https://trac.macports.org/changeset/112036 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [112027] trunk/dports/math/metis/Portfile
On Oct 9, 2013, at 19:38, j...@macports.org wrote: Revision: 112027 https://trac.macports.org/changeset/112027 Author: j...@macports.org Date: 2013-10-09 17:38:07 -0700 (Wed, 09 Oct 2013) Log Message: --- metis: correct license and formatting Modified Paths: -- trunk/dports/math/metis/Portfile Modified: trunk/dports/math/metis/Portfile === --- trunk/dports/math/metis/Portfile 2013-10-09 23:20:45 UTC (rev 112026) +++ trunk/dports/math/metis/Portfile 2013-10-10 00:38:07 UTC (rev 112027) @@ -8,7 +8,7 @@ categories math platforms darwin maintainers nomaintainer -license Apache-2.0 +license Apache-2 LGPL-2.1+ The metis LICENSE.txt says: Licensed under the Apache License, Version 2.0. It does not say or later or Version 2.x, so how do we know that any version 2 is ok? How do we know there won't be an Apache license version 2.1 in the future that has different terms? When I've found projects licensed under the Apache License version 2.0 I've tried to list them in the portfiles as Apache-2.0. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [112027] trunk/dports/math/metis/Portfile
On 2013-10-10 13:45 , Ryan Schmidt wrote: On Oct 9, 2013, at 19:38, j...@macports.org wrote: Revision: 112027 https://trac.macports.org/changeset/112027 Author: j...@macports.org Date: 2013-10-09 17:38:07 -0700 (Wed, 09 Oct 2013) Log Message: --- metis: correct license and formatting Modified Paths: -- trunk/dports/math/metis/Portfile Modified: trunk/dports/math/metis/Portfile === --- trunk/dports/math/metis/Portfile 2013-10-09 23:20:45 UTC (rev 112026) +++ trunk/dports/math/metis/Portfile 2013-10-10 00:38:07 UTC (rev 112027) @@ -8,7 +8,7 @@ categories math platforms darwin maintainers nomaintainer -license Apache-2.0 +license Apache-2 LGPL-2.1+ The metis LICENSE.txt says: Licensed under the Apache License, Version 2.0. It does not say or later or Version 2.x, so how do we know that any version 2 is ok? How do we know there won't be an Apache license version 2.1 in the future that has different terms? When I've found projects licensed under the Apache License version 2.0 I've tried to list them in the portfiles as Apache-2.0. 2 means 2.0 not 2.x. Keeping the .0 will break checking for license conflicts. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [112027] trunk/dports/math/metis/Portfile
On 2013-10-10 13:47 , Ryan Schmidt wrote:
And this means we have no syntax for indicating that a project would be under
Apache-2.x?
Right. In that case you'd have to do something like {Apache-2
Apache-2.1}. It doesn't seem to happen much in practice though.
- Josh
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
