Keep in mind that there was one overall design goal of git: Whenever there was
more than one right way to do something, do the opposite of svn.
That is not a joke or exaggeration.
Branches in git are dirt cheap -- they consist of creating a 40 byte file.
"git add" to put stuff into git is moder
On 2016-11-03, at 10:39 PM, David Bariod wrote:
> Hello,
>
> Personnally, I would just commit such change. It is cheap, can be reworked
> later and be ketp safe in a private remote repository in case of disaster.
> With git there are no reason to not commit event not ready yet change set.
>
>
On 2016-10-26, at 12:25 AM, Joshua Root wrote:
> On 2016-10-25 10:03 , Michael wrote:
>>
>> On 2016-10-24, at 2:57 PM, Marko Käning wrote:
>>
>>> Hi folks,
>>>
>>> when I read only the first two paragraphs of this thread...
>>>
>
On 2016-10-24, at 2:57 PM, Marko Käning wrote:
> Hi folks,
>
> when I read only the first two paragraphs of this thread...
>
> On 24 Oct 2016, at 18:37 , Michael wrote:
>> So since MacPorts is moving to git, and from what I saw in the "how to use
>> git&quo
> I think Michael is thinking:
>
> I have port 'foo' in macports and it requires a (rather large/complicated)
> patch that currently sits in files/ and has to be re-generated every time
> upstream releases a new version of 'foo'
>
> And essentially
On 2016-10-24, at 10:25 AM, Clemens Lang wrote:
> Hi,
>
> On Mon, Oct 24, 2016 at 09:37:37AM -0700, Michael wrote:
>> So since MacPorts is moving to git, and from what I saw in the "how to
>> use git" docs you mentioned, you apparently want people to work wit
So since MacPorts is moving to git, and from what I saw in the "how to use git"
docs you mentioned, you apparently want people to work with patchsets rebased
onto the current head from upstream.
As I was thinking about that, I realized that you lose your history of the
patchset in the process.
On 2016-10-21, at 8:03 PM, Lawrence Velázquez wrote:
>> On Oct 21, 2016, at 10:55 PM, Ryan Schmidt wrote:
>>
>>> On Oct 21, 2016, at 9:47 PM, Lawrence Velázquez wrote:
>>>
On Oct 21, 2016, at 10:20 PM, Craig Treleaven
wrote:
Also, is the consensus that a graphical user
I used the "DELETE FROM" command (using Sierra), and it worked nicely!
Thanks, Rainer! - MLD
On Thu, Oct 13, 2016, at 01:29 PM, Rainer Müller wrote:
> On macOS 10.12 Sierra, the cache appears to be stored in
> ~/Library/Keychains/*/ocspcache.sqlite3
>
> I do not know any official, documented way
I tried logging in to my MP account just now, and am getting the
following error (from Chrome; Safari does not even show this level of
info but it does not allow login either). Other websites work with https
property (not all, but many). Any advice on what's going on? - MLD
{{{
Your connection is
I was never able to find a library that provided that symbol / type; I
didn't get an issue with it until way into installing various ports
(maybe GNU Radio or UHD --> one with many dependencies). When I combine
that issue with: (1) the latest Xcode for 10.5.8 supplies at best
libstdc++ compliant wi
I don't think there's such a way to flag certain ports, but I'd love to
see it in place for exactly the reasons Mojca describes -- especially
for the purposes of "reclaim". - MLD
On Tue, Feb 23, 2016, at 02:43 PM, Mojca Miklavec wrote:
> I often deactivate certain "heavy" ports where I want to pla
Generally it's the project's poor build system that is at fault, and
needs to be tweaked / patched.
That said, I've seen a CMAKE variable that one can set that might help
out. Something like CMAKE_INCLUDE_EXTERNAL_HEADERS_LAST or the like. I
don't remember where I saw it, nor if it really works. C
On Mon, Feb 15, 2016, at 09:33 PM, Mihai Moldovan wrote:
> On 16.02.2016 01:34 AM, Michael Dickens wrote:
> > An example would be a "check and try update" task that would: do a
> > livecheck and if found to be old then automatically try to do the
> > update: c
+1: I like this idea, or at least what I think you're getting at. I'd
love to have a MP-sanctioned port related utility app for doing common
tasks -for developers-.
An example would be a "check and try update" task that would: do a
livecheck and if found to be old then automatically try to do the
I've enjoyed being a mentor thus far, so I'm game for seeing what comes
up if others are. Is SNC going to lead the way again? - MLD
On Fri, Feb 12, 2016, at 07:56 AM, Rainer Müller wrote:
> Paging those who handled this last year, is there any interest to participate
> again?
My bad for thinking Mojca wanted support for libstdc++. Somehow I really
misinterpreted the original postings. Happens sometimes. - MLD
On Mon, Jan 25, 2016, at 12:11 PM, Jeremy Huddleston Sequoia wrote:
> "libstdc++" means /usr/lib/libstdc++.6.dylib, and it doesn't support
> C++11, so it is not p
We've had this discuss before, how to do C++11 for libstdc++ and libc++.
The cxx11 PortGroup implements C++11 compliance for libc++ only. It
errors out when using libstdc++.
What Mojca is asking is whether we can add an implementation for when
using libstdc++, and I am on board with agreeing on h
On Jan 17, 2016 5:20 PM, "MacPorts" wrote:
>
> #50356: sudo: Update to 1.8.15, CVE-2015-5602
> +-
> Reporter: cal@… | Owner: youvegotmoxie@…
> Type: update | Status: new
> Priority: Normal | Milestone:
> Component: ports
On Thu, Jan 14, 2016, at 02:43 AM, Joshua Root wrote:
> > Revision: 144621
> > https://trac.macports.org/changeset/144621
> > Author: sean at macports.org
> > Date: 2016-01-13 23:29:24 -0800 (Wed, 13 Jan 2016)
> > Log Message:
> > ---
> > py-numpy: numpy needs fortran, so re
Ditto Ryan's reply. That said, I think SVN is actually OK for what
MacPorts needs. I greatly prefer GIT for actual software development,
because of the cloning, committing, branching, splitting, merging it
provides (offline or online, parts or whole, lots of usable options). I
use SVN for the MP tr
I'm interested! I'm working on updating QWT to be framework installs,
and I maintain Waco too. Thanks! - MLD
On Wed, Nov 25, 2015, at 03:57 AM, Vincent Habchi wrote:
> I’ve been able to patch the Portfiles for QScintilla and Qwt and get
> something useable with Qt5.
> If you’re interested in gett
Further (from another part of this email thread): It looks like setting
those to ${prefix}/lib or .../include does create anomalies here and
there in QTSG. Grr
I'll try your patches & see what comes of it. Thanks for getting those
figured out! - MLD
On Fri, Oct 30, 2015, at 02:56 PM
On Fri, Oct 30, 2015, at 12:37 PM, René J. V. Bertin wrote:
> René J. V. Bertin wrote:
>
> > Michael Dickens wrote:
> >
> >> The error you show below with qtscriptgenerator is because it does not
> >> find phonon
> >
> > Are you sure? When I remo
qmake to find phonon via the "CONFIG *= phonon"
command, and it fails because of the aforementioned reasons. - MLD
On Fri, Oct 30, 2015, at 11:18 AM, René J.V. Bertin wrote:
> Michael Dickens wrote:
>
> > is to make sure that either (1) "LIBS *= -L${prefix}/lib"
The error you show below with qtscriptgenerator is because it does not
find phonon & thus there is no cpp code generated --> but the build
system does not know this for some reason & tries to build anyway.
Adding in QCA-like qmake code into the phonon mkspec file does the trick
for finding phonon v
Here's my take: Qt4 needed to be moved out of the way to be installable
in parallel with Qt5, and, by moving everything into a location where
you have to know where it is, we really test the build systems for those
ports that use Qt4/5. Many ports, generally those that use the qt4 or
qmake PortGrou
qtscriptgenerator is having issues with locating phonon now that it's
not co-located with the qt4 install. Like QCA, it might make sense to
just co-locate phonon into the new qt4 install prefix. I'm looking into
it. - MLD
On Tue, Oct 27, 2015, at 05:48 PM, Marko Käning wrote:
> Answering my own qu
No problems. Thanks for the feedback. - MLD
On Wed, Oct 14, 2015, at 12:14 PM, Clemens Brunner wrote:
> I don't care and I won't be able to test with the new version either,
> sorry about that.
> On Oct 14, 2015 18:10, "MacPorts" wrote:
>> #39221: Cannot deploy Qt applications with MacPorts por
On Sun, Oct 11, 2015, at 01:49 PM, Ryan Schmidt wrote:
> On Oct 11, 2015, at 10:15 AM, michae...@macports.org wrote:
> > gr-fosphor: add a patch to fix finding Freetype2 headers, for those having
> > issues (e.g., in 10.11).
> Can you tell me more about this problem?
Hi Ryan - Sure. gr-fosphor
epends_lib-append`
>> yesterday, I guess I should check whether that change was in reaction
>> to this thread and if it addresses the issue I ran in to. The commit
>> message isn't very explicit about what's being appended to rather
>> than overwritten ...
>>
>
Hasn't worked for me since yesterday sometime. Definitely not any time
today (Thursday). I even tried manually entering in my (20 character)
random password (PITA) without success (didn't work with cut-and-paste
either, to be fair). Just gave up for now. - MLD
On Thu, Sep 3, 2015, at 01:27 PM, Dan
FYI follow-up:
{{{
% otool -L
/opt/local/var/macports/build/_opt_source_MacPorts_trunk_dports_lang_llvm-3.8/clang-3.8/work/destroot/opt/local/libexec/llvm-3.8/lib/clang/3.8/lib/darwin/libclang_rt.asan_osx_dynamic.dylib
/opt/local/var/macports/build/_opt_source_MacPorts_trunk_dports_lang_llvm-3.8/c
Can't search Trac so here it is; sorry about any duplication! I no
longer have the build log to see how this library was created in the
first place (e.g., with "-headerpad_max_install_names" or the like). -
MLD
{{{
:info:destroot llvm[2]: Installing compiler runtime library:
darwin/asan_osx_dynami
On Sep 1, 2015 7:17 PM, "Mihai Moldovan" wrote:
>
> On 01.09.2015 01:32 AM, Michael Beasley wrote:
> > Attached are patches for sysutils/mkpwd v1.6. (current version 0.8)
> > [...]
>
> A couple of comments on that one:
>
> Due to the project now using aut
Attached are patches for sysutils/mkpwd v1.6. (current version 0.8)
update-mkpwd.diff
patch-Makefile.am.diff - remove lcrypt
patch-Makefile.in.diff - remove lcrypt
patch-configure.diff - remove lcrypt
patch-mkpwd.c.diff - fix version information
patch-mkpwd.1.diff - fix incorrect man page in
> On Aug 25, 2015, at 6:41 PM, Michael Beasley wrote:
>
>
> On Aug 25, 2015 6:33 PM, "Charles Celerier" <mailto:ccel...@cs.stanford.edu>> wrote:
> >
> > Hello,
> >
> > I just recently became the maintainer for the Notmuch port. I was
> On Aug 25, 2015, at 5:01 PM, Charles Celerier wrote:
>
> Hello,
>
> I just recently became the maintainer for the Notmuch port. I was unable
> to find any information on the website about what my role entails. It
> appears that I do not have permission to commit patches to the port. Can
> I a
On Aug 25, 2015 6:33 PM, "Charles Celerier" wrote:
>
> Hello,
>
> I just recently became the maintainer for the Notmuch port. I was unable
> to find any information on the website about what my role entails. It
> appears that I do not have permission to commit patches to the port. Can
> I at least
This directory and -any- Qt directory should not make a difference if
the port is using this PortGroup and the project honors the variables
found in QMake (and here). I have no objection to the changes, except
that they should not be needed. Now that they are done, let's leave them
in place and fix
Maybe. I'll try that before a rev-bump next time. - MLD
On Sun, Jul 19, 2015, at 09:32 AM, Brandon Allbery wrote:
> On Sun, Jul 19, 2015 at 8:54 AM, Michael Dickens
> wrote:
>> This last time, after updating to the latest SVN
>>
trunk/base, I made the change but port sti
On Sat, Jul 18, 2015, at 05:08 PM, Joshua Root wrote:
> What do you mean by "port wouldn't recognize the change"?
What I was trying to do was fix a conflict between a port requiring
libusb, while I have libusb-devel installed (since the libusb and
libusb-devel ports necessarily conflict). I had ch
On Fri, Jul 17, 2015, at 06:21 PM, Ryan Schmidt wrote:
> > On Jul 17, 2015, at 1:07 PM, michae...@macports.org wrote:
> > +++ trunk/dports/science/gr-fcdproplus/Portfile 2015-07-17 18:07:53 UTC
> > (rev 138727)
> > +revision2
> > depends_lib-append port:boost \
> > +
On Mon, Jul 6, 2015, at 03:06 PM, Joshua Root wrote:
> On 2015-7-7 04:45 , Michael Dickens wrote:
> > I must have a short memory; I have no recollection of doing that commit.
> > Thanks for the explanation of why the 'm' or 'u' or 'd' or whatever; I
>
tweak them to use
libgcc files instead of going through any specific gcc port's files.
Anybody want to test? - MLD
On Tue, Jul 7, 2015, at 03:18 AM, Ryan Schmidt wrote:
> On Jul 5, 2015, at 12:50 PM, Michael Dickens wrote:
> > I've been working on a fix to this issue, but haven&
I must have a short memory; I have no recollection of doing that commit.
Thanks for the explanation of why the 'm' or 'u' or 'd' or whatever; I
had forgotten that too. Reading through that PEP, seems like we can use
the Python sysconfig variable 'INCLUDEPY' to determined the include
install locatio
Even something as minimal as making the default checked directory on
python34 end with "m" works for me; it's probably not the ideal
solution, but it's better than what we have right now. - MLD
{{{
Index: _resources/port1.0/group/python-1.0.tcl
=
After updating py34-pyqt4 to use dbus-python34, all of the buildbots
failed to build this port, with:
{{{
configure.py: error:
"/opt/local/Library/Frameworks/Python.framework/Versions/3.4/include/python3.4m/dbus-1.0"
is not a directory
}}}
This port builds cleanly for me on 10.8 (latest; latest Xco
This change does not change current behavior, and fixes an issue that
would have effected future behavior. Thanks for checking! - MLD
On Sun, Jul 5, 2015, at 08:03 PM, Ryan Schmidt wrote:
>
> On Jul 5, 2015, at 12:49 PM, Brandon Allbery wrote:
> >
> > On Sun, Jul 5, 2015 a
On Sat, Jul 4, 2015, at 11:53 PM, Brandon Allbery wrote:
> On Sat, Jul 4, 2015 at 11:51 PM, Ryan Schmidt wrote:
>> > + fix correcting of .pc files for any install location, not just
>> > when in ${prefix}.
>>
>>
When would it not be in prefix?
>
> When it's in a subdirectory of $prefix, so it ca
There's a PortGroup for handling the Fortran compiler selection from the
command line. The difficult job is getting the selection from the CL
into the Python setup script. As Petr and I have written, some projects
do this more robustly than others. If you have a Portfile you can share
with us, we m
In CMake, to find an exact required specific version, you can use EXACT
and REQUIRED, e.g:
find_package(python 3.4.3 EXACT REQUIRED)
That said, the provided FindPython sucks, in that if multiple versions
of Python are installed it will generally find part in the
CMAKE_INSTALL_PREFIX and another
Hi Mojca - Fortran and Python aren't generally the easiest mix. NumPy
and SciPy struggle with them, too. Some projects provide a reasonable
configuration or setup interface into which one can specify a specific
compiler for CC, CXX, F90, FF, whatever & their *FLAGS too; some don't.
I haven't looked
I fixed the configure.cmd in a future commit.
I'd love to see the github change moved to the port group; not sure
that's the best way to go for all ports though. - MLD
On Sat, Jun 6, 2015, at 06:51 PM, Ryan Schmidt wrote:
>
> > On Jun 4, 2015, at 6:01 PM, michae...@macports.org wrote:
> >
> >
Yes, thanks for catching that. Clearly I had a different ticket open
when I was doing cut-and-paste. Fixed in the revision commit as well as
the Portfile (r136489). - MLD
On Mon, May 18, 2015, at 08:10 PM, Ryan Schmidt wrote:
>
> > On May 18, 2015, at 1:17 PM, michae...@macports.org wrote:
> >
>
Done in r135941. Thanks! - MLD
On Thu, May 7, 2015, at 02:29 AM, Ryan Schmidt wrote:
> If the old to-be-removed variant does something that is not the default,
> and to do that now requires some other variant, then what you've written
> would be needed.
>
> However, in your case, you want the to-
On Wed, May 6, 2015, at 08:45 PM, Ryan Schmidt wrote:
> > +# legacy postgresql variants; can be removed 2016-05-01
> > +# use of < 8.3 removed as of 2.3.2.
> > +
> > +set legacy_postgresql_suffixes {80 81 82}
> > +
> > +foreach s ${legacy_postgresql_suffixes} {
> > +set p postgresql${s}
> > +
OK; I think I get the point now; thanks for that additional information,
Ryan.
I think the key here is "support", in the sense of what MacPorts will
guarantee is supposed to work (configurations MacPorts supports):
* MacPorts -does not guarantee- that libstdc++ will work for C++11
support (when u
Yes; OK; agreed in general.
So, why do we have "configure.cxx_stdlib"? Why not just force users to
use libc++ and never libstdc++? I know this setting -can be- per port,
but for (guessing) 99%+ of all users they just use the default (they
likely do not even know they can change this setting). On 1
Hmmm ... so, at least for my primary ports (gnuradio, volk, uhd), when
using libstdc++ as the default (which is true for 10.8 and prior), I
find that GCC 4.7 and newer supports -std=c++11 correctly. Not so for
GCC 4.6 and older, nor for any Clang (Apple or MacPorts -- which seem to
use the legacy g
NP. I haven't switched to using the cxx11 PortGroup; I'll look into that
instead of what I'm doing & that might solve the issue for me. Thanks
for all the feedback! - MLD
On Wed, May 6, 2015, at 02:33 PM, Lawrence Velázquez wrote:
> Err sorry, for some reason I assumed that volk was using the cxx1
As a "related aside", running lint on my current volk port (which moves
the compilers_blacklist_version PortGroup into just where it is needed),
results in:
{{{
% port lint --nitpick volk
---> Verifying Portfile for volk
Error: Line 35 uses compiler.blacklist in a way that requires the
compiler_bl
Thanks for the pointers on using {} only when using [] but not *; I'll
update the Portfile shortly. I prefer to be "transparent" in compiler
selection, so blacklisting even compilers that won't be chosen is better
than not & really does no harm.
As for using the compiler_blacklist_versions, there
Interesting; the macro is actually "_GLIBCXX_USE_C99_MATH_TR1", with
just 1 preceding "_"; at least on my 10.8 & 10.10 installs.
This macro is set at
"/opt/local/include/gcc49/c++/x86_64-apple-darwin12/bits/c++config.h:1276"
on my install, which is part of the configuration of GCC. So, I'd guess
t
types.h:27,
from /opt/local/include/gnuradio/io_signature.h:27,
from FILE.cc:25:
/usr/include/architecture/i386/math.h:307:15: note: "log2";
extern double log2 ( double );
}}}
On Wed, Apr 22, 2015, at 04:02 PM, Mihai Moldovan wrote:
> On 22.04.2015 09:51 PM, Michael
One of my ports won't build on the 10.6 buildbot, because it claims the
following (snipped for brevity):
{{{
/opt/local/bin/g++-mp-4.9 [snip] -std=c++11 -o FILE.cc.o -c FILE.cc
FILE.cc: In constructor "FILE(std::vector >)":
FILE.cc:46:54: error: "log2" is not a member of "std"
(unsi
n order
to then move on to 3.6.0 and libc++ but got stuck on a mis-linking issue
with ld64-127.2. The current version doesn't fix that but doesn't seem
to work any worse either.
--
Hope it's of use to someone,
Michael
___
macports-dev
Yes, that will work. I had seen the "deactivate hack" in some other
ports, but didn't see a way to check for "contents". Moving that check
to a version check will work. Thanks - MLD
On Sun, Apr 5, 2015, at 10:42 PM, Lawrence Velázquez wrote:
> Sounds like you actually want the deactivate hack.
>
I'm in the process of splitting of a project (volk) from a port
(gnuradio); until last week they were provided in the same repo, and now
they are provided as 2 separate repos (but, volk is still required to
build gnuradio). This split is currently for gnuradio-(devel,next) only;
the release will ca
On Fri, Mar 20, 2015, at 04:38 AM, Chris Jones wrote:
> Using Macports gcc you will still have the problem of mixing different
> C++ runtimes, the macports stdlibc++ used by the gcc ports, and the
> system one. They are not the same and if you try use at the same time
> ports built with the norm
On Thu, Mar 19, 2015, at 02:06 PM, Lawrence Velázquez wrote:
> On Mar 19, 2015, at 1:56 PM, Michael Dickens
> wrote:
> > Exactly. If we key off of {${configure.cxx_stdlib} eq "libstdc++"}, then
> > I think this can be made to work; er, mostly.
>
> I believe this
So, here's what I have thus far:
{{{
if {${configure.cxx_stdlib} eq "libstdc++"} {
# *clang* when using libstdc++ do not seem to support C++11;
# C++11 support seems to need GCC 4.7+ when using libstdc++;
# could use C++0x support on GCC4.[56], but just ignore it since
# there are
On Thu, Mar 19, 2015, at 01:54 PM, René J.V. Bertin wrote:
> On Thursday March 19 2015 17:01:02 Chris Jones wrote:
>
> > Using gcc is a bad idea, this can lead to C++ runtime issues.
>
> On newer OS X versions where libc++ is the default (or only) C++ runtime.
Exactly. If we key off of {${config
I have a few ports that have recently moved to requiring c++11 (or,
maybe, c++0x), and a few to-be-submitted ports that do too, so I'm
wondering if there's a standard way to specify this requirement -- for
example, something like:
{{{
PortGroup compilers 1.0
compilers.setup require_cxx11
Yes, that's true: I can have any number, and they are executed in the
order declared. The Octave PortGroup's post-patch would always be
declared first, and it (1) creates a tarball of the current worksrcpath,
then (2) deletes the worksrcpath since it is not used by the Octave pkg
installer. So, if
On Thu, Feb 19, 2015, at 09:55 AM, Clemens Lang wrote:
> This basically boils down to re-factoring the dependency engine, something
> which I think has been due for a while. While doing that we could also
> improve it (or at least make some preparations to improve it, e.g. to support
> variant d
I would love to see this feature added to the "upgrade" process; or,
really, any time a port is installed (in general). Right now, port will
print a list of ports to be installed that are not already installed. It
would be nice for port to print those dependencies needing to be
upgraded (for any re
OK; good to know this is a known issue and is being actively addressed.
Thanks! - MLD
On Tue, Feb 17, 2015, at 09:53 AM, Ryan Schmidt wrote:
> On Feb 17, 2015, at 8:37 AM, Michael Dickens wrote:
> >
> > Looks like the Mavericks buildbot is hosed; can someone
Looks like the Mavericks buildbot is hosed; can someone kick it? - MLD
{{{
Building ports
Building uhd (1 of 1)...Error: Port uhd not found
[snip]
touch: /var/tmp/failcache/uhd: No such file or directory
}}}
- Original message -
From: nore...@macports.org
To: michae...@macports.org
Subjec
FYI that I created a unified patch to bring the CMake port to 3.1.2 from
the current SVN head, and attached it to the appropraite ticket <
https://trac.macports.org/ticket/46493#comment:12 >. I think this change
keeps the same functionality with the Darwin Platform changes as before;
the CMake devs
Hi René - We have tried to get the use of [Mm]odules to be just with
'M', since that's the way CMake does it internally. We fixed the CMake
PortGroup a while back, and I'd guess that most of the projects using it
have been rev-bumped since then -- and, most of them now correctly
install into the ${
Looks like the MTLN build-bot has a bad file:
{{{
Error: org.macports.activate for port boost returned: Image error:
/opt/local/include/boost/accumulators/accumulators.hpp already exists
and does not belong to a registered port. Unable to activate port
boost.
}}}
- Original message -
From
With a simple patch to the octave-interval Makefile to remove the use of
CFLAGS and LDFLAGS directly when calling mkoctfile,the port now works
nicely for me (using 10.8, libstdc++; we'll see if the build bots like
it). Committed in r132525. - MLD
___
mac
the 0.1.0 release, then it's most likely "their bad" and probably
nothing to do with MacPorts (meaning: MacPorts' settings for these flags
has not changed, but the package's usage of the flags has). - MLD
On Sun, Feb 1, 2015, at 09:19 PM, Michael Dickens wrote:
> octave-1.
octave-1.0.tcl only uses what is provided to it by octave itself via
'mkoctfile' (specifically the FLIBS and LAPACK_LIBS settings); it does
nothing special or tricky along the way even if the way it handles
building octave packages is nonstandard. Those settings should not
contain '-arch' of any t
On Tue, Jan 20, 2015, at 02:26 PM, René J.V. Bertin wrote:
> I suppose you're not supporting any random swig version, so how about
> doing what the python Portfile itself does, a foreach over a list of
> known versions? swig-python and swig-python-devel both don't install a
> single common file?
I
On Tue, Jan 20, 2015, at 02:17 PM, Lawrence Velázquez wrote:
> The depspec is interpreted as a regular expression (with some caveats),
> not a glob. For instance, my HandBrake WIP portfile contains this:
>
> depends_build port:autoconf \
> port:automake \
>
I've been working on getting a "swig-devel" port up and running, and it
works locally for me. But in order to use it (e.g.,
"swig-python-devel"), I need to specify dependencies using a wildcard
because we don't know the SWIG version. For example, something like:
{{{
depends-build-append path:share/
Hi Sean - Some Python ports require these variables to be set in
multiple phases. I don't think setting them in multiple phases hurts the
other ports (those that get the flags during configure or build, and
don't use them in any other phase). Things seem to work right now, and
adding these variable
In my experience, we don't want QTDIR set when compiling Qt. Otherwise I
would not have included that variable (hack) in the first place. I can't
say what happens if it is set; don't remember any longer; probably Qt
just fails building.
My point was: If you trace the "building_qt#" variable throug
>From the top of the qt4-mac Portfile:
{{{
# use the qt4 group; set 'building_qt4' so that the portgroup
# does not include certain parts
set building_qt41
}}}
This variable is designed just for the purpose you need for qt4-mac; it
would not be difficult to add to qt5-mac if it is not already i
On Tue, Jan 6, 2015, at 08:34 PM, Bradley Giesbrecht wrote:
> I'm going to attach my patch to your ticket if for no other reason then allow
> the use of the trac diff viewer to show interested parties how small the
> changes really are.
Yes, please do attach your patches! Fewer patches == easier
On Tue, Jan 6, 2015, at 12:52 PM, René J.V. Bertin wrote:
> On Tuesday January 06 2015 11:48:46 Michael Dickens wrote:
>
> > There just isn't enough time in the day! Some day, I won't be so crazy
> > busy! Some day, I really will address the Qt4 tickets. I really do
There just isn't enough time in the day! Some day, I won't be so crazy
busy! Some day, I really will address the Qt4 tickets. I really do like
the idea of having Qt4 and Qt5 available at the same time & I know that
Qt4 needs some attention (as does Qt5, but I haven't even found time for
the Qt4 stu
One issue with how SWIG is split up is that much of the wrapping code
logic is built in to the binary provided by "swig". Installing
"swig-python" just installs the headers & related data files used by
SWIG (which are necessary, but not sufficient). I'm not sure if Python
needs to be available duri
On Sun, Jan 4, 2015, at 09:58 PM, Lawrence Velázquez wrote:
> On Jan 4, 2015, at 3:46 PM, Michael Dickens
> wrote:
>
> > That said, ports that -rely- on swig-python will probably need to be
> > rev-bumped, because they will have a library/libraries linked against
> > t
Looking at the contents of swig-python, I'm guessing it'll work just
fine without any changes. It looks like what is installed are scripts
that provide an interface into Python in a generic way, providing
different code segments for the different Python versions. So, I don't
think it'll be an issue
Good question! I'd guess that since python{24,25,26} will be replaced by
python27 (ditto for the 3 series, I'm assuming) in the Portfile(s) that
they use, then the user will need to re-select the Python to use. Or,
maybe use what I did in qt4-mac when I removed its select: put in a
post-activate ho
NP; will hold off. Have fun refactoring! - MLD
On Wed, Dec 31, 2014, at 02:52 PM, Sean Farley wrote:
>
> Michael Dickens writes:
>
> > I ment to send this to macports-dev, not macports-changes. So, echoing
> > what Josh just wrote:
> >
> > On Wed, Dec 31, 2
I ment to send this to macports-dev, not macports-changes. So, echoing
what Josh just wrote:
On Wed, Dec 31, 2014, at 11:08 AM, Michael Dickens wrote:
py*-cython is still used by py*-scipy and py*-numpy (edit: among other
ports). If we're ready to disable non-Python 2.7 and 3.4 scipy and
1 - 100 of 493 matches
Mail list logo
