Re: f2py: request for help
On 2015-10-30 03:28 , Rainer Müller wrote: > On 2015-10-28 20:20, Mojca Miklavec wrote: >> Apart from the fact that I don't know how to get a binary called >> "f2py" (it would be nice to have the executable without the extension >> available), running >> f2py-3.5 -c fib1.f -m fib1 >> fails to find the Fortran compiler as it looks for gfortran only. > > Clear the option that controls the addition of the suffix: > > python.link_binaries_suffix Probably better to add the directory containing the unprefixed executable to PATH, rather than reintroduce the conflict between the different subports? - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Memory consumption for py-pyobjc-cocoa
Hi, When I try to compile pyX.Y-pyobjc-cocoa my computer freezes. The compilation consumes all the available memory (> 6 GB, the swap keeps growing, ...) and then I usually force-quit Python after a while because something seems suspicious. Is the huge memory consumption normal/expected? I don't remember any similar problems from the past, but it's also true that the compilation was usually done on the buildbot way back. Thank you, Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: All KDE ports need a major revbump, due to recent changes to qt4-mac
Michael Dickens wrote:
> qmake PortGroups, just needed a rev-bump. Some ports such as phonon
> install files that =assume= the same install prefix as Qt, and so when
> they are installed elsewhere everything breaks down for ports that
> depend on them (e.g., using qmake to find phonon fails unless some
> library located in ${prefix}/lib is included before phonon; cmake and
I haven't had any issues with phonon; what ports (using qmake?) break when
phonon isn't installed in Qt's prefix?
The question is also what the Qt prefix is, if everything is NOT installed in
an
all-encompassing prefix. Qt5 is more flexible in this aspect; with my install
layout it considers the prefix to be ${prefix}, despite the fact that the bin
and lib dirs are in ${prefix}/libexec/qt5 .
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: All KDE ports need a major revbump, due to recent changes to qt4-mac
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 PortGroups, just needed a rev-bump. Some ports such as phonon
install files that =assume= the same install prefix as Qt, and so when
they are installed elsewhere everything breaks down for ports that
depend on them (e.g., using qmake to find phonon fails unless some
library located in ${prefix}/lib is included before phonon; cmake and
pkgconfig, when variables are set correctly, work nicely).
Once the vast majority of ports have been fixed to work with the new
Qt4/5 location, we can figure out where we actually want stuff to go &
fix it -- for example, moving all Qt4/5 pkgconfig files to be in
${prefix}/lib/pkgconfig/; cmake files into ${prefix}/share/cmake/... .
In the meantime, let's get the ports that are failing when using Qt4/5
working -- I think this should be our priority right now. So, this means
fixing phonon's mkspec file to do the right thing no matter where phonon
is installed; and, fixing qtscriptgenerator -- which BTW has been broken
off and on for along time because it has been EOL for 2-3 years. I'll be
working on these in the coming days; I think I've got a fix for the
former, and am making slow progress on the latter too. Fun times! - MLD
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Please test trace mode on El Capitan
- On 27 Oct, 2015, at 22:51, Clemens Lang c...@macports.org wrote: > I didn't see this in my test runs, but maybe I just overlooked it. I guess we > should just add that path to the trace whitelist, because it's basically > /usr/bin or /bin anyway. Should be fixed in r141852. -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: All KDE ports need a major revbump, due to recent changes to qt4-mac
Ohoh, so this is finally where I get to say "I told you so"?
@Michael Dickens wrote:
> 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.
Yeah, and while ye-all are at it, why not co-locate everything that depends on
Qt4 in the new qt4 prefix?
In other words: "le monde à l'envers"
@Craig wrote
> Something I wondered about was the choice of ${prefix}/libexec/blah
Quite a few ports ("base" and llvm/clang included) use libexec as prefix-in-a-
prefix. When I proposed libexec/qt4 and libexec/qt5 (sic) way back,it seemed
more
in line with existing practice to abuse the libexec directory than the lib
directory. After all, libexec can be read as "lib[s] plus exec[s]", which is
exactly the case *for my install layout*.
@Mojca wrote:
> In my opinion it is also *much* better if CMake and pkg-config files
> end up where they are supposed to be.
Yep. With CMake it's less clear what exactly that place, since there are
several
locations that are used (and not each by a single port). But in any case, I
think it's safest not to change such locations from what the port intends (and
other ports/packages will expect) if it is not to use a central location
instead.
> (There are also many other files
> like "libexec/qt4/share/doc" that could easily be in "share/doc/qt4/"
> etc, even though those are not as critical.)
Of course. There was never a reason to move those in the 1st place, and that
includes share/qtN/* (which includes mkspecs and plugins).
I also don't see why the headers should be hidden so deeply. Installing them in
${prefix}/include/qtN works just fine, and makes reading build logs a lot more
legible.
@Rainer wrote:
> I only noticed this now, but it seems this change will cause problems:
Did you miss my "about MacPorts principles, conventions (and dogmata :)) re:
install layouts and Qt" message on this ML?
> Please do not simply drop everything related to Qt into its own prefix.
Hear hear ... I have been insisting on that for almost a year now, to no avail.
> I definitely don't want to discredit the work of René
Thanks, I for one didn't think you did. In fact, I understand that no one wants
to do that, but there clearly isn't much intent to more than doing verbal
credit
to my work either.
(Which is why I caught wind of this thread only now: I stopped following ML
activity that is not in reaction to a query of my own.)
> I understand that some of these parts conflict in filename
Way less that you'd think actually, largely because the original install schema
already used qt4 and qt5 directories (in ${prefix}/share) and because the Qt5
libraries and a number of other installed (Qt5) files have some form of Qt5 in
their names.
Let's not forget that Qt5 was designed to co-install with Qt4 with minimal
effort even on platforms where Qt is (almost) part of the system libraries.
That
is also why there's something called qtchooser.
@Rainer asked:
> What was the reason for moving Qt4 into its own prefix? I guess this is
> about allowing Qt4 and Qt5 to be installed at the same time?
It has to do with that, yes. Marko's guess notwithstanding, the real reason I
have seen invoked is
"Qt itself installs like that on OS X"
To put it bluntly: that is true, but completely irrelevant. (Qt-for-OS X itself
doesn't intend to be used the way it is in MacPorts.)
> * binaries in ${prefix}/libexec/qt4/bin are inaccessible and not in PATH
Guilty as charged even with my install layout. However:
- I provide symlinks suffixed with -qt4 and -qt5 for a number of commonly used
execs
- there is port:qtchooser which also installs symlinks, to itself, and then
acts
as a wrapper that can be configured to proxy for multiple Qt installs
(including
a default install). A bit like a port select scheme, but more flexible.
R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: All KDE ports need a major revbump, due to recent changes to qt4-mac
On Thu, Oct 29, 2015 at 6:02 PM, Rainer Müller wrote:
> On 2015-10-29 17:05, Mojca Miklavec wrote:
>>
>> When 10.11 came out (where Qt 4 no longer worked), the
>> switch to Qt 5 and moving Qt 4 away suddenly had to be done in a
>> hurry, so the maintainer decided for the easier path to simply put
>> everything under the same prefix.
>
> I understand that some of these parts conflict in filename, but the
> files I mentioned do not. They can co-exist in ${prefix}/lib/pkgconfig/
> or ${prefix}/share/cmake/ (Qt* for qt4 and Qt5* for qt5). I see no
> reason to move these files.
In my opinion it is also *much* better if CMake and pkg-config files
end up where they are supposed to be. (There are also many other files
like "libexec/qt4/share/doc" that could easily be in "share/doc/qt4/"
etc, even though those are not as critical.)
It's just that it was a lot easier to move those files (just add
--prefix=... to configure) than not to move them at that time.
If it was a smaller package, I would say "let's just commit the change
that fixes that", but it might be wise to at least collect all the
changes that are worth making and that are "safe enough" to make to
avoid unnecessary rebuilds. (But then again not to wait forever.)
>> Any port than requires Qt should include one of the two qt portgroups
>> that sets all the necessary variables, so that even if Qt 4/5 layout
>> changes again, it should be a simple matter of a revbump of
>> dependents.
>
> That is correct for use of Qt by dependent ports. However, if a user
> wants to compile software from source which is not yet provided in a
> port (or builds their own version for development), manually setting up
> PKG_CONFIG_PATH and/or CMAKE_MODULE_PATH is cumbersome.
True. (Even though that is also a problem for many other
ports/libraries that we ship.)
Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: All KDE ports need a major revbump, due to recent changes to qt4-mac
On 2015-10-29 17:05, Mojca Miklavec wrote:
> This special layout is something that René has been working on for
> months, but nobody looked into his work for a very long time (and
> nobody felt the pressing need to fix the situation with conflicting
> Qt4 and Qt5).
This is true what you say about reviewing. I stuck with Qt4 only as long
as the Qt versions conflicted.
I definitely don't want to discredit the work of René and others for
getting Qt4 and Qt5 along. Thank you for working on this!
> When 10.11 came out (where Qt 4 no longer worked), the
> switch to Qt 5 and moving Qt 4 away suddenly had to be done in a
> hurry, so the maintainer decided for the easier path to simply put
> everything under the same prefix.
I understand that some of these parts conflict in filename, but the
files I mentioned do not. They can co-exist in ${prefix}/lib/pkgconfig/
or ${prefix}/share/cmake/ (Qt* for qt4 and Qt5* for qt5). I see no
reason to move these files.
> Qt4 and Qt5 are maintained by different people which complicates matters a
> bit.
>
> I still hope that the idea is to eventually:
> - put different things under appropriate prefixes (like the three
> examples mentioned above)
> - unify paths for Qt 4 and Qt 5 (the is no need to use a "-mac" postfix)
>
> Any port than requires Qt should include one of the two qt portgroups
> that sets all the necessary variables, so that even if Qt 4/5 layout
> changes again, it should be a simple matter of a revbump of
> dependents.
That is correct for use of Qt by dependent ports. However, if a user
wants to compile software from source which is not yet provided in a
port (or builds their own version for development), manually setting up
PKG_CONFIG_PATH and/or CMAKE_MODULE_PATH is cumbersome.
Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: f2py: request for help
On 2015-10-29 17:38, Mojca Miklavec wrote: > On Thu, Oct 29, 2015 at 5:28 PM, Rainer Müller wrote: >> On 2015-10-28 20:20, Mojca Miklavec wrote: >>> Apart from the fact that I don't know how to get a binary called >>> "f2py" (it would be nice to have the executable without the extension >>> available), running >>> f2py-3.5 -c fib1.f -m fib1 >>> fails to find the Fortran compiler as it looks for gfortran only. >> >> Clear the option that controls the addition of the suffix: >> >> python.link_binaries_suffix > > Then 2.7, 3.4 and 3.5 will all try to create the same binary, f2py. Ah, well, I did not understand this is part of NumPy. > What we need is probably some "port select" option, but then again > f2py should probably be "compatible" with the version of python that > has already been selected with "port select python". I have no clue > how to achieve that. Port select python could not create a f2py > symlink as that one comes from numpy. In the way we treat python software, a port is meant to either: a) provides a python module (with pyXY-* subports) b) provides a standalone tool (with optional +pythonXY variants) In this case, py-numpy provides both modules and tools, so the outcome is not ideal. You end up with the suffixed tools as multiple pyXY-numpy ports can be installed at the same time for different python versions. Other ports such as ipython, pyflakes, pylint provide their own select files. Rainer ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: f2py: request for help
On Thu, Oct 29, 2015 at 5:28 PM, Rainer Müller wrote: > On 2015-10-28 20:20, Mojca Miklavec wrote: >> Apart from the fact that I don't know how to get a binary called >> "f2py" (it would be nice to have the executable without the extension >> available), running >> f2py-3.5 -c fib1.f -m fib1 >> fails to find the Fortran compiler as it looks for gfortran only. > > Clear the option that controls the addition of the suffix: > > python.link_binaries_suffix Then 2.7, 3.4 and 3.5 will all try to create the same binary, f2py. What we need is probably some "port select" option, but then again f2py should probably be "compatible" with the version of python that has already been selected with "port select python". I have no clue how to achieve that. Port select python could not create a f2py symlink as that one comes from numpy. Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: f2py: request for help
On 2015-10-28 20:20, Mojca Miklavec wrote: > Apart from the fact that I don't know how to get a binary called > "f2py" (it would be nice to have the executable without the extension > available), running > f2py-3.5 -c fib1.f -m fib1 > fails to find the Fortran compiler as it looks for gfortran only. Clear the option that controls the addition of the suffix: python.link_binaries_suffix I can't help with the other problem related to Fortran compiler, though. Rainer ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Problems with github & livecheck
On 2015-10-29 16:47, Mojca Miklavec wrote:
> I'm getting some weird results with the livecheck with respect to gate:
>
>> port info gate
> gate @7.1_4 (science)
> ...
>> port -v livecheck gate
> gate seems to have been updated (port version: e657ed0c, new version: v7.0)
>
> This is the relevant part of the code that apparently confuses the livecheck:
>
> PortGroup github 1.0
> set git_sha e657ed0c
> github.setupOpenGATE Gate ${git_sha}
> namegate
> version 7.1
> revision4
>
> Does anyone have any idea how to overcome this?
The github portgroup configures livecheck to use the version which was
passed to github.setup. When you overwrite it to use the actual
${version} and change the
livecheck.version${version}
However, since the archives have a tag prefix of 'v' or 'V' that the
port group does not know about, you also need to tweak the regex.
livecheck.regex archive/\[vV\](\[^"\]+)${extract.suffix}
You can see the URL and regex being used when running with debug output,
for example 'port -d livecheck gate'.
Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Problems with github & livecheck
On Thu, Oct 29, 2015 at 4:55 PM, Jeremy Lavergne wrote:
> On Thu, October 29, 2015 11:47, Mojca Miklavec wrote:
>>
>> I'm getting some weird results with the livecheck with respect to gate:
>>
>>> port info gate
>> gate @7.1_4 (science) ...
>>
>>> port -v livecheck gate
>> gate seems to have been updated (port version: e657ed0c, new version:
>> v7.0)
>>
>> This is the relevant part of the code that apparently confuses the
>> livecheck:
>>
>>
>> PortGroup github 1.0
>> set git_sha e657ed0c github.setupOpenGATE Gate ${git_sha}
>> namegate version 7.1 revision4
>>
>> Does anyone have any idea how to overcome this?
>
> Livecheck likely also has a version variable, separate from the
> non-livecheck version.
>
> github.setup probably sets both version variables, so I'd recommend
> reading the github.setup proc in dports/_resources/
Ah, thank you. It makes sense now.
I can add
livecheck.version ${version}
and then it at least becomes more human-readable (even if not really useful).
Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: All KDE ports need a major revbump, due to recent changes to qt4-mac
On Thu, Oct 29, 2015 at 4:09 PM, Rainer Müller wrote:
> On 2015-10-27 22:24, Marko Käning wrote:
>> Hi Nicolas,
>>
>> while building kdevelop and kdepim4 I came across some rev-upgrades… Thus I
>> have rebumped ports kate, libkgapi and konversation.
>>
>> For instance, the latter tried to find libqca in it’s old location
>> ---
>> Dyld Error Message:
>> Library not loaded: /opt/local/lib/libqca.2.dylib
>> Referenced from:
>> /Applications/MacPorts/*/konversation.app/Contents/MacOS/konversation
>> Reason: image not found
>> ---
>> which has - in the meantime - moved into $PREFIX/libexec/qt4/lib/:
>
> What was the reason for moving Qt4 into its own prefix? I guess this is
> about allowing Qt4 and Qt5 to be installed at the same time?
>
> I only noticed this now, but it seems this change will cause problems:
>
> * binaries in ${prefix}/libexec/qt4/bin are inaccessible and not in PATH
> * pkg-config files in ${prefix}/libexec/qt4/lib/pkgconfig/ will not be
> found by default (needs additional PKG_CONFIG_PATH)
> * cmake modules in ${prefix}/libexec/qt4/share/cmake/ will not be found
> by default (needs additional CMAKE_MODULE_PATH)
>
> The same seems to apply to qt5-mac as well. Also, the choice of
> ${prefix}/libexec/qt4/ vs. ${prefix}/libexec/qt5-mac/ looks inconsistent.
>
> Please do not simply drop everything related to Qt into its own prefix.
> At least keep the files mentioned above in the default locations where
> they can be found and used by other build systems.
This special layout is something that René has been working on for
months, but nobody looked into his work for a very long time (and
nobody felt the pressing need to fix the situation with conflicting
Qt4 and Qt5). When 10.11 came out (where Qt 4 no longer worked), the
switch to Qt 5 and moving Qt 4 away suddenly had to be done in a
hurry, so the maintainer decided for the easier path to simply put
everything under the same prefix.
Qt4 and Qt5 are maintained by different people which complicates matters a bit.
I still hope that the idea is to eventually:
- put different things under appropriate prefixes (like the three
examples mentioned above)
- unify paths for Qt 4 and Qt 5 (the is no need to use a "-mac" postfix)
Any port than requires Qt should include one of the two qt portgroups
that sets all the necessary variables, so that even if Qt 4/5 layout
changes again, it should be a simple matter of a revbump of
dependents.
Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: All KDE ports need a major revbump, due to recent changes to qt4-mac
> On Oct 29, 2015, at 11:09 AM, Rainer Müller wrote:
>
> What was the reason for moving Qt4 into its own prefix? I guess this is
> about allowing Qt4 and Qt5 to be installed at the same time?
>
> I only noticed this now, but it seems this change will cause problems:
>
> * binaries in ${prefix}/libexec/qt4/bin are inaccessible and not in PATH
> * pkg-config files in ${prefix}/libexec/qt4/lib/pkgconfig/ will not be
> found by default (needs additional PKG_CONFIG_PATH)
> * cmake modules in ${prefix}/libexec/qt4/share/cmake/ will not be found
> by default (needs additional CMAKE_MODULE_PATH)
>
> The same seems to apply to qt5-mac as well. Also, the choice of
> ${prefix}/libexec/qt4/ vs. ${prefix}/libexec/qt5-mac/ looks inconsistent.
>
> Please do not simply drop everything related to Qt into its own prefix.
> At least keep the files mentioned above in the default locations where
> they can be found and used by other build systems.
Something I wondered about was the choice of ${prefix}/libexec/blah . The
other example of co-installable versions/forks that I’m familiar with is mysql.
Those ports install the binaries into ${prefix}/lib/blah (e.g..
/opt/local/lib/mariadb/bin/ ). I have no idea if one approach is “right”—just
that the mysql structure has been around longer and could be considered a
precedent.
Craig
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Problems with github & livecheck
Hi,
I'm getting some weird results with the livecheck with respect to gate:
> port info gate
gate @7.1_4 (science)
...
> port -v livecheck gate
gate seems to have been updated (port version: e657ed0c, new version: v7.0)
This is the relevant part of the code that apparently confuses the livecheck:
PortGroup github 1.0
set git_sha e657ed0c
github.setupOpenGATE Gate ${git_sha}
namegate
version 7.1
revision4
Does anyone have any idea how to overcome this?
Thank you,
Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: All KDE ports need a major revbump, due to recent changes to qt4-mac
On 2015-10-27 22:24, Marko Käning wrote:
> Hi Nicolas,
>
> while building kdevelop and kdepim4 I came across some rev-upgrades… Thus I
> have rebumped ports kate, libkgapi and konversation.
>
> For instance, the latter tried to find libqca in it’s old location
> ---
> Dyld Error Message:
> Library not loaded: /opt/local/lib/libqca.2.dylib
> Referenced from:
> /Applications/MacPorts/*/konversation.app/Contents/MacOS/konversation
> Reason: image not found
> ---
> which has - in the meantime - moved into $PREFIX/libexec/qt4/lib/:
What was the reason for moving Qt4 into its own prefix? I guess this is
about allowing Qt4 and Qt5 to be installed at the same time?
I only noticed this now, but it seems this change will cause problems:
* binaries in ${prefix}/libexec/qt4/bin are inaccessible and not in PATH
* pkg-config files in ${prefix}/libexec/qt4/lib/pkgconfig/ will not be
found by default (needs additional PKG_CONFIG_PATH)
* cmake modules in ${prefix}/libexec/qt4/share/cmake/ will not be found
by default (needs additional CMAKE_MODULE_PATH)
The same seems to apply to qt5-mac as well. Also, the choice of
${prefix}/libexec/qt4/ vs. ${prefix}/libexec/qt5-mac/ looks inconsistent.
Please do not simply drop everything related to Qt into its own prefix.
At least keep the files mentioned above in the default locations where
they can be found and used by other build systems.
Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
