Re: svn fetch multiple directories
Just my to cents: - One could fetch files from SVN, zip them, checksum the zip, store the zip as if the zip was fetched from elsewhere and just unzip that file during the repeated installation. Fetching from SVN doesn't mean that we cannot use checksums and other benefits. - It would be nice to support sparse checkouts. They shouldn't be particularly hard to implement (but I'm not too familiar with Tcl). Based on the following example: svn checkout file:///tmp/repos/test file:///tmp/repos/quiz working-copies the sparse checkout would be svn co --depth=empty file:///tmp/repos svn up $wd/repos/test svn up $wd/repos/quiz ($wd – working dir where svn checkout has been made) Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Releasing code as portgroup instead of in base/
On 2014-10-14 09:31 , Daniel J. Luke wrote:
> Another way to look at it is that generally the portgroup is unversioned (and
> an end user doesn't necessarily know which version of a portgroup was used
> when a particular port was installed).
JFYI, ${prefix}/var/macports/registry/portgroups now contains all
distinct portgroup files used by installed ports, and the registry
entries reference them.
- Josh
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [126684] trunk/dports/python
Note that subports' revisions must be bumped when they're moved to the
graveyard, otherwise upgrades won't be triggered.
https://trac.macports.org/changeset/126706
vq
On Oct 13, 2014, at 1:54 PM, m...@macports.org wrote:
> Revision
> 126684
> Author
> m...@macports.org
> Date
> 2014-10-13 10:54:58 -0700 (Mon, 13 Oct 2014)
> Log Message
>
> py-pysparse: Remove py26 sub-port. remove myself as maintainer.
> Modified Paths
>
> trunk/dports/python/py-graveyard/Portfile
> trunk/dports/python/py-pysparse/Portfile
> Diff
>
> Modified: trunk/dports/python/py-graveyard/Portfile (126683 => 126684)
>
> --- trunk/dports/python/py-graveyard/Portfile 2014-10-13 17:52:50 UTC (rev
> 126683)
> +++ trunk/dports/python/py-graveyard/Portfile 2014-10-13 17:54:58 UTC (rev
> 126684)
> @@ -69,6 +69,7 @@
> pylons 1.0.1rc1_1 26
> pymacs 0.25_1 25 26
> pyqwt 5.2.0_1026
> +pysparse1.1.1_1 26
> rbtools 0.4.3_1 24 25 26
> repl0.8.1_1 24 25 26
> rfc3339 5_1 25 26
> Modified: trunk/dports/python/py-pysparse/Portfile (126683 => 126684)
>
> --- trunk/dports/python/py-pysparse/Portfile 2014-10-13 17:52:50 UTC (rev
> 126683)
> +++ trunk/dports/python/py-pysparse/Portfile 2014-10-13 17:54:58 UTC (rev
> 126684)
> @@ -9,7 +9,7 @@
> revision1
> categories-append math
> platforms darwin
> -maintainers mf2k vcn.com:jjstickel openmaintainer
> +maintainers vcn.com:jjstickel openmaintainer
> license BSD
>
> description a fast sparse matrix library for Python
> @@ -24,7 +24,7 @@
> sha1dca36520f39551781bcaeac8c1bbc6d3baefa57a \
> rmd160 0848e7f061d0d2571bbad3e4fd2b4e0f070b961a
>
> -python.versions 26 27
> +python.versions 27
>
> if {${name} ne ${subport}} {
> depends_lib port:py${python.version}-numpy
> ___
> macports-changes mailing list
> macports-chan...@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-changes
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Releasing code as portgroup instead of in base/
On Oct 13, 2014, at 6:51 PM, Ryan Schmidt wrote: > On Oct 13, 2014, at 5:31 PM, Daniel J. Luke wrote: > >> it seems like that is a problem with base/ and our dev documentation (or >> lack of) which it would make sense to fix rather than work around it in that >> way. > > We don't have any documentation of base, do we? Not really. Section 6.4 of the Guide is probably the closest we have. https://guide.macports.org/#internals.apis vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [126702] trunk/dports/devel/libdvdread/Portfile
At 9:37 PM -0500 10/13/14, Ryan Schmidt wrote: > On Oct 13, 2014, at 9:33 PM, ctrelea...@macports.org wrote: [...] > -configure.cmd ./autogen.sh +configure.args-append --disable-silent-rules Since you're no longer using "configure.cmd ./autogen.sh", do you still need "depends_build port:autoconf port:automake port:libtool"? Good point, I'll test tomorrow... Craig ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [126702] trunk/dports/devel/libdvdread/Portfile
> On Oct 13, 2014, at 9:33 PM, ctrelea...@macports.org wrote:
>
> Revision
> 126702
> Author
> ctrelea...@macports.org
> Date
> 2014-10-13 19:33:00 -0700 (Mon, 13 Oct 2014)
> Log Message
>
> libdvdread: update to 5.0.0, new master_site
> Modified Paths
>
> • trunk/dports/devel/libdvdread/Portfile
> @@ -22,12 +22,12 @@
> 3. A simple library for parsing the navigation (NAV) packets \
> (nav_read.h/nav_types.h).
>
> -homepagehttp://dvdnav.mplayerhq.hu/
> -master_sites${homepage}releases/
> +homepagehttp://dvdnav.mplayerhq.hu/
> +master_sites
> http://download.videolan.org/pub/videolan/${name}/${version}/
>
> -use_xz yes
> -checksums rmd160 50ae1afbbabc5a8640dbf065184f52af38d0ef6d \
> -sha256
> af9b98f049580a6521d56c978b736d3d609562dd12955e11d50e26d97542dcd4
> +use_bzip2 yes
> +checksums rmd160 91c663a52acb45e4a1a96d33591a7649e6b0807b \
> +sha256
> 66fb1a3a42aa0c56b02547f69c7eb0438c5beeaf21aee2ae2c6aa23ea8305f14
>
> depends_build port:autoconf port:automake port:libtool
> depends_lib port:libdvdcss
> @@ -37,7 +37,7 @@
> reinplace -locale C "s|@@PREFIX@@|${prefix}|"
> ${worksrcpath}/src/dvd_input.c
> }
>
> -configure.cmd ./autogen.sh
> +configure.args-append --disable-silent-rules
Since you're no longer using "configure.cmd ./autogen.sh", do you still need
"depends_build port:autoconf port:automake port:libtool"?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Releasing code as portgroup instead of in base/
On Oct 13, 2014, at 5:31 PM, Daniel J. Luke wrote: > On Oct 13, 2014, at 6:19 PM, Ryan Schmidt wrote: >> There's no difference in the capabilities of code in a portgroup vs code in >> a portfile. > > portfiles are usually simpler than portgroups (almost by definition). > > a portfile that looks like a few key-value pairs is a lot easier to > trust/validate than something that sources a bunch of tcl from a portgroup. I suppose so. I never considered that there might be users that would actually read a port's / portgroup's / base's code to validate it before installing a port. Do such people actually exist? In any case, the point of putting code into a portgroup is to abstract out code common to a set of ports. It's easier to write that code once, correctly, than to copy and paste it into several ports where it has a chance to become out of sync and incorrect. It should also be easier for an interested reader to read and understand that code once in one place than to see it repeated all over the place, and especially to understand any subtle differences that might exist between the copies. >> I also see a problem if a port uses a portgroup, and wants to use two >> different ports, at different revisions, that expect different versions of >> the portgroup. Is this kind of problem the reason why you're against >> portgroups? > > this is one of the reasons why I find them somewhat problematic, yes. > > Another way to look at it is that generally the portgroup is unversioned (and > an end user doesn't necessarily know which version of a portgroup was used > when a particular port was installed). We do have versionability in portgroups, it just hasn't been used much so far. But in terms of revisions of portgroup, anyone who cares can find out what revision of the portgroup was in use at the time the port was installed. The portfile that was used is in the installed archive, its $Id$ line contains the port's revision, and the corresponding revision of the portgroup that existed at that time can be obtained. >> I do want there to be lots of metadata about ports on the new MacPorts web >> site, including information such as results of buildbot builds. If we get to >> the point of automating test runs that could be included as well. The web >> site could also make that information available to the command line MacPorts >> program in some way if we wanted to do that. > > I think that would be great. > > If I were writing macports from scratch, I might have 'remote portfiles' be > the default, you would ping a portfile server to see what was available, or > pull whatever recipe for building a port that you selected. End users could > select various criteria that they wanted enforced (only install ports that > have been reviewed by a MP committer, only install ports that passed a test > suite, only install ports that are GPL compliant, only instal ports that > built on the buildbot...). It could be simpler for people to (attempt to) > install a port at a particular version/revision too. > > ... but those additional capabilities are probably of marginal utility for > most people, so I don't think that they're reasonable immediate design goals > - instead there are clearly some areas where we can and should continue to > improve. Mhm, I think these days the "sudo port selfupdate" step is a stumbling block for many, who expect things to just automatically be up to date. Because if so, that would be stifling, and if not, then I don't see it working very well, since it's previous been very convenient to be able to make changes in portgroups simultaneously with changes in ports. Losing that ability will make working with portgroup more difficult. >>> >>> it's not all or nothing, but I think we should generally push more code >>> into base/ (especially after an portgroup has matured somewhat) rather than >>> pushing for more and more code out of base/ >> >> Even for decade-old build systems like imake that are only used by a handful >> of ports? > > yes, for as long as we wanted to support imake builds > >> That would for me be the definition of special-case code that doesn't belong >> in base. > > most of base could be construed as special-case code ;-) I can't really understand this position at all. In my view, most of base deals with things most ports need. >> The other thing I really like about portgroups is that all code related to a >> particular thing is contained within a single file. When I want to >> investigate a feature in base, I have to first use grep to figure out what >> file(s) the code is in, and it's usually spread out all over the place. In >> the case of imake support, it's only in two files, portconfigure.tcl and >> portutil.tcl, but that first file is 800 lines long and, like most of base, >> hard to read, for someone otherwise only accustomed to reading portfiles. >> Having all the imake- (or whatever-) rela
Re: Releasing code as portgroup instead of in base/
On Oct 13, 2014, at 6:19 PM, Ryan Schmidt wrote: > > On Oct 13, 2014, at 5:00 PM, Daniel J. Luke wrote: >> On Oct 13, 2014, at 5:54 PM, Ryan Schmidt wrote: >> On Oct 10, 2014, at 9:05 AM, Daniel J. Luke wrote: > I disagree that we should move as many portgroups as possible into base. > Moving the portgroups out of base and into the ports tree years ago has > been of great benefit in encouraging the development of portgroups. No > matter how agile the release process of base may become, nothing compares > to being able to put a file in a directory and having it available to the > entire MacPorts userbase in minutes. right - and I'm saying that that's actually a problem 'easy' injection of code into the tree without going through any kind of release process/review is something we should minimize. >>> >>> Playing devil's advocate for a moment, are you suggesting that we institute >>> a similar release process/review for portfile changes? >> >> we should continue improving base/ (non-root execution, sandboxing, trace >> mode, etc) so that 'rogue' portfiles cannot do damage (or can do limited >> damage) so that this isn't necessary (or is less necessary). > > Sure, and we're already pretty good at that, and will continue to get better. > But if Portfiles cannot do damage, they still can (currently) > then portgroups, which are merely code included by portfiles, cannot do > damage either. There's no difference in the capabilities of code in a > portgroup vs code in a portfile. portfiles are usually simpler than portgroups (almost by definition). a portfile that looks like a few key-value pairs is a lot easier to trust/validate than something that sources a bunch of tcl from a portgroup. > I also see a problem if a port uses a portgroup, and wants to use two > different ports, at different revisions, that expect different versions of > the portgroup. Is this kind of problem the reason why you're against > portgroups? this is one of the reasons why I find them somewhat problematic, yes. Another way to look at it is that generally the portgroup is unversioned (and an end user doesn't necessarily know which version of a portgroup was used when a particular port was installed). > I do want there to be lots of metadata about ports on the new MacPorts web > site, including information such as results of buildbot builds. If we get to > the point of automating test runs that could be included as well. The web > site could also make that information available to the command line MacPorts > program in some way if we wanted to do that. I think that would be great. If I were writing macports from scratch, I might have 'remote portfiles' be the default, you would ping a portfile server to see what was available, or pull whatever recipe for building a port that you selected. End users could select various criteria that they wanted enforced (only install ports that have been reviewed by a MP committer, only install ports that passed a test suite, only install ports that are GPL compliant, only instal ports that built on the buildbot...). It could be simpler for people to (attempt to) install a port at a particular version/revision too. ... but those additional capabilities are probably of marginal utility for most people, so I don't think that they're reasonable immediate design goals - instead there are clearly some areas where we can and should continue to improve. >>> Because if so, that would be stifling, and if not, then I don't see it >>> working very well, since it's previous been very convenient to be able to >>> make changes in portgroups simultaneously with changes in ports. Losing >>> that ability will make working with portgroup more difficult. >> >> it's not all or nothing, but I think we should generally push more code into >> base/ (especially after an portgroup has matured somewhat) rather than >> pushing for more and more code out of base/ > > Even for decade-old build systems like imake that are only used by a handful > of ports? yes, for as long as we wanted to support imake builds > That would for me be the definition of special-case code that doesn't belong > in base. most of base could be construed as special-case code ;-) > The other thing I really like about portgroups is that all code related to a > particular thing is contained within a single file. When I want to > investigate a feature in base, I have to first use grep to figure out what > file(s) the code is in, and it's usually spread out all over the place. In > the case of imake support, it's only in two files, portconfigure.tcl and > portutil.tcl, but that first file is 800 lines long and, like most of base, > hard to read, for someone otherwise only accustomed to reading portfiles. > Having all the imake- (or whatever-) related code in a single short portgroup > file is much easier to understand and change. it se
Re: Releasing code as portgroup instead of in base/
On Oct 13, 2014, at 5:00 PM, Daniel J. Luke wrote: > On Oct 13, 2014, at 5:54 PM, Ryan Schmidt wrote: > >>> On Oct 10, 2014, at 9:05 AM, Daniel J. Luke wrote: >>> I disagree that we should move as many portgroups as possible into base. Moving the portgroups out of base and into the ports tree years ago has been of great benefit in encouraging the development of portgroups. No matter how agile the release process of base may become, nothing compares to being able to put a file in a directory and having it available to the entire MacPorts userbase in minutes. >>> >>> right - and I'm saying that that's actually a problem >>> >>> 'easy' injection of code into the tree without going through any kind of >>> release process/review is something we should minimize. >> >> Playing devil's advocate for a moment, are you suggesting that we institute >> a similar release process/review for portfile changes? > > we should continue improving base/ (non-root execution, sandboxing, trace > mode, etc) so that 'rogue' portfiles cannot do damage (or can do limited > damage) so that this isn't necessary (or is less necessary). Sure, and we're already pretty good at that, and will continue to get better. But if Portfiles cannot do damage, then portgroups, which are merely code included by portfiles, cannot do damage either. There's no difference in the capabilities of code in a portgroup vs code in a portfile. > It would actually be really nice if we kept metadata about individual > portfile revisions that indicated if they had been reviewed / had passed some > tests, etc. so that end-users could choose what level of > validation/verification is appropriate for the environment that they're > running in. An interesting idea, but a significant departure from our current situation of only allowing the use of the latest version of a port. I also see a problem if a port uses a portgroup, and wants to use two different ports, at different revisions, that expect different versions of the portgroup. Is this kind of problem the reason why you're against portgroups? I do want there to be lots of metadata about ports on the new MacPorts web site, including information such as results of buildbot builds. If we get to the point of automating test runs that could be included as well. The web site could also make that information available to the command line MacPorts program in some way if we wanted to do that. >> Because if so, that would be stifling, and if not, then I don't see it >> working very well, since it's previous been very convenient to be able to >> make changes in portgroups simultaneously with changes in ports. Losing that >> ability will make working with portgroup more difficult. > > it's not all or nothing, but I think we should generally push more code into > base/ (especially after an portgroup has matured somewhat) rather than > pushing for more and more code out of base/ Even for decade-old build systems like imake that are only used by a handful of ports? That would for me be the definition of special-case code that doesn't belong in base. The other thing I really like about portgroups is that all code related to a particular thing is contained within a single file. When I want to investigate a feature in base, I have to first use grep to figure out what file(s) the code is in, and it's usually spread out all over the place. In the case of imake support, it's only in two files, portconfigure.tcl and portutil.tcl, but that first file is 800 lines long and, like most of base, hard to read, for someone otherwise only accustomed to reading portfiles. Having all the imake- (or whatever-) related code in a single short portgroup file is much easier to understand and change. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Releasing code as portgroup instead of in base/
On Oct 13, 2014, at 5:54 PM, Ryan Schmidt wrote: > > >> On Oct 10, 2014, at 9:05 AM, Daniel J. Luke wrote: >> >>> I disagree that we should move as many portgroups as possible into base. >>> Moving the portgroups out of base and into the ports tree years ago has >>> been of great benefit in encouraging the development of portgroups. No >>> matter how agile the release process of base may become, nothing compares >>> to being able to put a file in a directory and having it available to the >>> entire MacPorts userbase in minutes. >> >> right - and I'm saying that that's actually a problem >> >> 'easy' injection of code into the tree without going through any kind of >> release process/review is something we should minimize. > > Playing devil's advocate for a moment, are you suggesting that we institute a > similar release process/review for portfile changes? we should continue improving base/ (non-root execution, sandboxing, trace mode, etc) so that 'rogue' portfiles cannot do damage (or can do limited damage) so that this isn't necessary (or is less necessary). It would actually be really nice if we kept metadata about individual portfile revisions that indicated if they had been reviewed / had passed some tests, etc. so that end-users could choose what level of validation/verification is appropriate for the environment that they're running in. > Because if so, that would be stifling, and if not, then I don't see it > working very well, since it's previous been very convenient to be able to > make changes in portgroups simultaneously with changes in ports. Losing that > ability will make working with portgroup more difficult. it's not all or nothing, but I think we should generally push more code into base/ (especially after an portgroup has matured somewhat) rather than pushing for more and more code out of base/ -- 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 https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Releasing code as portgroup instead of in base/
> On Oct 10, 2014, at 9:05 AM, Daniel J. Luke wrote: > >> I disagree that we should move as many portgroups as possible into base. >> Moving the portgroups out of base and into the ports tree years ago has been >> of great benefit in encouraging the development of portgroups. No matter how >> agile the release process of base may become, nothing compares to being able >> to put a file in a directory and having it available to the entire MacPorts >> userbase in minutes. > > right - and I'm saying that that's actually a problem > > 'easy' injection of code into the tree without going through any kind of > release process/review is something we should minimize. Playing devil's advocate for a moment, are you suggesting that we institute a similar release process/review for portfile changes? Because if so, that would be stifling, and if not, then I don't see it working very well, since it's previous been very convenient to be able to make changes in portgroups simultaneously with changes in ports. Losing that ability will make working with portgroup more difficult. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: svn fetch multiple directories
On Oct 13, 2014, at 4:47 PM, Daniel J. Luke wrote: > it may be worthwhile to step back and figure out why the port has to checkout > from svn at all. In general we should discourage (ab)using source control > repositories in this way. It's /much/ better to be able to get a download > file that can be mirrored/checksumed etc. They don't release downloads very often (the last one was in 2011). Mark ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: svn fetch multiple directories
On Oct 13, 2014, at 5:27 PM, Ryan Schmidt wrote: > On Oct 13, 2014, at 4:15 PM, Mark Brethen wrote: >> On Oct 13, 2014, at 4:10 PM, Ryan Schmidt wrote: >>> Why do you need to fetch from multiple URLs? >> >> The repository contains files for windows, linux, etc. (everything but the >> kitchen sink) which is unnecessary for macports (the install takes an hour >> because I'm limited to checking out the whole trunk for each subport). > > OK. So if we did cache svn checkouts, that would help in that you wouldn't > have to spend a lot of time downloading, but you would still have unnecessary > files on disk. > > Recent versions of svn include pretty good support for sparse checkouts, but > MacPorts doesn't have any support for that, so if you wanted to make use of > that you'd have to write custom fetch code again. :/ > > In this case I'd probably set svn.url to the "main" URL, i.e. whichever URL > will provide the largest amount of data, and then use a post-fetch block to > get the rest of them. This way if we do eventually cache the checkout from > the svn.url, you'll get the biggest benefit. it may be worthwhile to step back and figure out why the port has to checkout from svn at all. In general we should discourage (ab)using source control repositories in this way. It's /much/ better to be able to get a download file that can be mirrored/checksumed etc. We should reserve the other ways of getting distfiles for extraordinary circumstances (which this might be one, but it's useful to remind people that it really should be a last resort). -- 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 https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: svn fetch multiple directories
On Oct 13, 2014, at 4:15 PM, Mark Brethen wrote: > On Oct 13, 2014, at 4:10 PM, Ryan Schmidt wrote: > >> Why do you need to fetch from multiple URLs? > > The repository contains files for windows, linux, etc. (everything but the > kitchen sink) which is unnecessary for macports (the install takes an hour > because I'm limited to checking out the whole trunk for each subport). OK. So if we did cache svn checkouts, that would help in that you wouldn't have to spend a lot of time downloading, but you would still have unnecessary files on disk. Recent versions of svn include pretty good support for sparse checkouts, but MacPorts doesn't have any support for that, so if you wanted to make use of that you'd have to write custom fetch code again. :/ In this case I'd probably set svn.url to the "main" URL, i.e. whichever URL will provide the largest amount of data, and then use a post-fetch block to get the rest of them. This way if we do eventually cache the checkout from the svn.url, you'll get the biggest benefit. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Temporarily supporting only one Python in a port
On Oct 12, 2014, at 4:04 PM, Davide Liessi wrote: > Dear MacPorts developers, > in the next update to the Portfile for Frescobaldi, I'm going to > remove the python26 variant (in the way suggested in [1]). > At the moment the program supports only Python 2.7, but we are > planning to support Python 3 soon (no precise deadline, though). > In the meanwhile, should I keep the (default) python27 variant in > place, or should I remove it (move its content out of the braces) and > add it again later together with variant python34? Probably simpler to keep it, but either is fine. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: svn fetch multiple directories
On Oct 13, 2014, at 4:10 PM, Ryan Schmidt wrote: > Why do you need to fetch from multiple URLs? The repository contains files for windows, linux, etc. (everything but the kitchen sink) which is unnecessary for macports (the install takes an hour because I'm limited to checking out the whole trunk for each subport). Mark ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: make clean preceding make all
On Oct 12, 2014, at 3:16 PM, Mark Brethen wrote:
> How does one setup a portfile to do a 'make clean' before a 'make all'? I
> thought of using
>
>pre-build {
>system -W ${somedir} "${build.cmd} clean"
>}
Usually one doesn't want to do this, but in the unusual situation where the
distributed tarball includes incorrect pre-built content (e.g. a distfile
distributed with already-build Linux object files, which I've encountered
once...), your pre-build block above is a fine way to accomplish it. It also
gives you a good place to insert a comment about why you're doing this.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: svn fetch multiple directories
On Oct 12, 2014, at 6:30 PM, Mark Brethen wrote:
> On Oct 12, 2014, at 4:23 PM, Mark Brethen wrote:
>
>> I'm breaking up an svn into different subports. It would save download time
>> if I can checkout only the directories needed from the repository for each
>> subport. Can you give multiple URLs for 'svn.url'? Similar to:
>>
>> $ svn checkout file:///tmp/repos/test file:///tmp/repos/quiz working-copies
>>
>> which checks out 2 different directories, but places both into a directory
>> called working-copies.
>>
>> This isn't covered in the macports documentation.
>
> Although svn allows checking out with more than one URL, apparently port does
> not:
>
> ---> Fetching distfiles for reduce-common
> Error: org.macports.fetch for port reduce-common returned: Subversion URL
> cannot contain whitespace
>
> Any one know why? Is there a work around I can use?
"Why" is:
* because all fetch phases that fetch from a version control system do so via a
single URL
* I was not aware that you could fetch from multiple URLs in a single "svn
checkout" command
* many ports were abusing svn.url to include arbitrary commands; I wanted to
put an end to that practice
* changing this would probably make the desired feature of cacheability --
https://trac.macports.org/ticket/16373 -- difficult to implement, so I would
not want to change this now.
Why do you need to fetch from multiple URLs?
On Oct 12, 2014, at 9:24 PM, Mark Brethen wrote:
> Or, how about:
>
> fetch {
> svn checkout file:///tmp/repos/test file:///tmp/repos/quiz ${worksrcpath}
> }
There is no Tcl or MacPorts command called "svn", so you must mean:
fetch {
system -W ${workpath} "svn co file:///tmp/repos/test
file:///tmp/repos/quiz"
}
However that would override any caching support we might eventually add to
MacPorts, so I would not do that.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: port ${name}
On Oct 13, 2014, at 9:44 AM, Mark Brethen wrote:
>
> On Oct 13, 2014, at 7:41 AM, Brandon Allbery wrote:
>
>> On Mon, Oct 13, 2014 at 8:33 AM, Mark Brethen wrote:
>>> If a user tries to install port ${name} how should this be handled?
>>
>> That depends on what exactly you're trying to do. Obvious possibilities
>> include installing all subports or some common subset thereof, via
>> dependencies possibly modified by variants: a classic metaport.
>
> How would you install all subports?
>
> if {${name} == ${subport}} {
Use "eq", not "==", for string comparisons.
>depends_build-appendsubport1 subport2 subport3
>configure no
>build {}
>destroot {}
> }
>
> like this?
All ports must install at least one file. You can look at other metaports to
see what they do. Typically they create a file called README and put either a
placeholder message or the port's description into it.
You'll also want to set "supported_archs noarch" and clear "distfiles", and you
may as well clear "archive_sites" too.
I've requested that we make these kinds of ports easier by introducing a "stub"
keyword, but we don't have this yet.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: port ${name}
On Oct 13, 2014, at 7:41 AM, Brandon Allbery wrote:
> On Mon, Oct 13, 2014 at 8:33 AM, Mark Brethen wrote:
> If a user tries to install port ${name} how should this be handled?
>
> That depends on what exactly you're trying to do. Obvious possibilities
> include installing all subports or some common subset thereof, via
> dependencies possibly modified by variants: a classic metaport.
>
> --
> brandon s allbery kf8nh sine nomine associates
> allber...@gmail.com ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
How would you install all subports?
if {${name} == ${subport}} {
depends_build-appendsubport1 subport2 subport3
configure no
build {}
destroot {}
}
like this?
Mark
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: port ${name}
On Mon, Oct 13, 2014 at 8:33 AM, Mark Brethen
wrote:
> If a user tries to install port ${name} how should this be handled?
That depends on what exactly you're trying to do. Obvious possibilities
include installing all subports or some common subset thereof, via
dependencies possibly modified by variants: a classic metaport.
--
brandon s allbery kf8nh sine nomine associates
allber...@gmail.com ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
port ${name}
My portfile uses subports to install the various sources in an svn repository.
The port name isn't used at all. Are there examples of this?
If a user tries to install port ${name} how should this be handled?
Mark
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: make clean preceding make all
On 2014-10-13 03:11, Lawrence Velázquez wrote: > Note that, as Ryan and I found out in #45274, GNU Make (at least) doesn't > sequentially run command-line goals to completion if it's told to operate in > parallel. So there's no guarantee that the "clean" target will finish before > the "all" target starts. > > https://trac.macports.org/ticket/45274 Good catch. I am used to this approach on the command line during development. I never experienced the problem of parallel execution there. Your objection makes sense. > A somewhat uglier (but more reliable) fix would be to patch the makefile to > make "clean" a dependency of "all". Yes, it is more work to maintain a patch just for that, especially if the Makefile was generated by automake. Rainer ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
