Re: [131743] trunk/dports/perl/p5-opengl
On 2015-1-17 16:30 , David Evans wrote: > On 1/16/15 9:12 PM, Ryan Schmidt wrote: >>> On Jan 16, 2015, at 5:59 PM, dev...@macports.org wrote: >>> >>> Revision >>> 131743 >>> Author >>> dev...@macports.org >>> Date >>> 2015-01-16 15:59:39 -0800 (Fri, 16 Jan 2015) >>> Log Message >>> >>> p5-opengl: update to version 0.6704, use the right compiler, license. >>> Modified: trunk/dports/perl/p5-opengl/Portfile (131742 => 131743) >>> +# can be distributed under the same terms as Perl itself >>> +# see http://search.cpan.org/dist/OpenGL/OpenGL.pod#AUTHORS >>> +# however, to correctly configure OpenGL capabilities, >>> +# it must be able to access the display on the >>> +# target machine during the configure phase >>> +# set license to unknown to suppress binary distribution >>> +license unknown >> It would be better to set the license correctly. If you want to >> suppress binary distribution, clear archive_sites e.g. by writing: >> >> archive_sites >> >> on a line by itself. >> >> > It's probably a moot distinction but I was trying not to generate a > faulty binary on the buildbot. I believe your solution just keeps me > from loading one. Or am I wrong? The binary will be built no matter what. The license can only prevent it from being copied to the public packages server. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [131743] trunk/dports/perl/p5-opengl
On Sat, Jan 17, 2015 at 6:30 AM, David Evans wrote: > > It's probably a moot distinction but I was trying not to generate a faulty > binary on the buildbot. Since when does it even build successfully? On https://build.macports.org/builders/buildports-lion-x86_64/builds/26390: _RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL. 2015-01-16 21:51:36.987 glversion[14695:407] invalid CoreGraphics connection 2015-01-16 21:51:36.988 glversion[14695:407] invalid CoreGraphics connection 2015-01-16 21:51:36.988 glversion[14695:407] GLUT Fatal Error: pixel format with necessary capabilities not found. make: *** [glversion.txt] Error 1 But I see that it builds on 10.9 and 10.10. Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [131724] trunk/dports/databases/gigabase/Portfile
> On Jan 16, 2015, at 8:14 AM, strom...@macports.org wrote: > > Revision > 131724 > Author > strom...@macports.org > Date > 2015-01-16 06:14:06 -0800 (Fri, 16 Jan 2015) > Log Message > > gigabase: update to version 3.91 > Modified: trunk/dports/databases/gigabase/Portfile (131723 => 131724) > +configure.compiler macports-gcc-4.8 Why is gcc48 being forced? Usually that's not desired and you didn't give a reason in the log message. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [131743] trunk/dports/perl/p5-opengl
On 1/16/15 9:31 PM, Ryan Schmidt wrote: On Jan 16, 2015, at 11:30 PM, David Evans wrote: On 1/16/15 9:12 PM, Ryan Schmidt wrote: On Jan 16, 2015, at 5:59 PM, dev...@macports.org wrote: Revision 131743 Author dev...@macports.org Date 2015-01-16 15:59:39 -0800 (Fri, 16 Jan 2015) Log Message p5-opengl: update to version 0.6704, use the right compiler, license. Modified: trunk/dports/perl/p5-opengl/Portfile (131742 => 131743) +# can be distributed under the same terms as Perl itself +# see http://search.cpan.org/dist/OpenGL/OpenGL.pod#AUTHORS +# however, to correctly configure OpenGL capabilities, +# it must be able to access the display on the +# target machine during the configure phase +# set license to unknown to suppress binary distribution +license unknown It would be better to set the license correctly. If you want to suppress binary distribution, clear archive_sites e.g. by writing: archive_sites on a line by itself. It's probably a moot distinction but I was trying not to generate a faulty binary on the buildbot. I believe your solution just keeps me from loading one. Or am I wrong? You're right. But that's what we've been doing in other ports that want to prevent users from getting binaries, such as atlas. OK, fixed in r131749. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [131743] trunk/dports/perl/p5-opengl
On Jan 16, 2015, at 11:30 PM, David Evans wrote: > > On 1/16/15 9:12 PM, Ryan Schmidt wrote: >>> On Jan 16, 2015, at 5:59 PM, dev...@macports.org wrote: >>> >>> Revision >>> 131743 >>> Author >>> dev...@macports.org >>> Date >>> 2015-01-16 15:59:39 -0800 (Fri, 16 Jan 2015) >>> Log Message >>> >>> p5-opengl: update to version 0.6704, use the right compiler, license. >>> Modified: trunk/dports/perl/p5-opengl/Portfile (131742 => 131743) >>> +# can be distributed under the same terms as Perl itself >>> +# see http://search.cpan.org/dist/OpenGL/OpenGL.pod#AUTHORS >>> +# however, to correctly configure OpenGL capabilities, >>> +# it must be able to access the display on the >>> +# target machine during the configure phase >>> +# set license to unknown to suppress binary distribution >>> +license unknown >> It would be better to set the license correctly. If you want to suppress >> binary distribution, clear archive_sites e.g. by writing: >> >> archive_sites >> >> on a line by itself. > > It's probably a moot distinction but I was trying not to generate a faulty > binary on the buildbot. I believe your solution just keeps me from loading > one. Or am I wrong? You're right. But that's what we've been doing in other ports that want to prevent users from getting binaries, such as atlas. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [131743] trunk/dports/perl/p5-opengl
On 1/16/15 9:12 PM, Ryan Schmidt wrote: On Jan 16, 2015, at 5:59 PM, dev...@macports.org wrote: Revision 131743 Author dev...@macports.org Date 2015-01-16 15:59:39 -0800 (Fri, 16 Jan 2015) Log Message p5-opengl: update to version 0.6704, use the right compiler, license. Modified: trunk/dports/perl/p5-opengl/Portfile (131742 => 131743) +# can be distributed under the same terms as Perl itself +# see http://search.cpan.org/dist/OpenGL/OpenGL.pod#AUTHORS +# however, to correctly configure OpenGL capabilities, +# it must be able to access the display on the +# target machine during the configure phase +# set license to unknown to suppress binary distribution +license unknown It would be better to set the license correctly. If you want to suppress binary distribution, clear archive_sites e.g. by writing: archive_sites on a line by itself. It's probably a moot distinction but I was trying not to generate a faulty binary on the buildbot. I believe your solution just keeps me from loading one. Or am I wrong? Dave ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [131743] trunk/dports/perl/p5-opengl
> On Jan 16, 2015, at 5:59 PM, dev...@macports.org wrote: > > Revision > 131743 > Author > dev...@macports.org > Date > 2015-01-16 15:59:39 -0800 (Fri, 16 Jan 2015) > Log Message > > p5-opengl: update to version 0.6704, use the right compiler, license. > Modified: trunk/dports/perl/p5-opengl/Portfile (131742 => 131743) > +# can be distributed under the same terms as Perl itself > +# see http://search.cpan.org/dist/OpenGL/OpenGL.pod#AUTHORS > +# however, to correctly configure OpenGL capabilities, > +# it must be able to access the display on the > +# target machine during the configure phase > +# set license to unknown to suppress binary distribution > +license unknown It would be better to set the license correctly. If you want to suppress binary distribution, clear archive_sites e.g. by writing: archive_sites on a line by itself. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: qt5- prefix
On Fri, Jan 16, 2015 at 4:11 PM, René J.V. wrote: > > I only picked the qt5- prefix because there's some precedence, though > admittedly Qt Creator has a qt4- prefix for the Qt4 version. > Similarly, GTk ports indeed have -gtk2 or -gtk3 suffixes ... though there it > might be more usual to have a GTk2 dependency be the implicit default. > >> I find the "qt5-" prefix objectionable. > > Frankly, I don't know and I don't have a real preference: I'm open to > suggestions. > We do have the likely situation where more and more ports will transition to, > or at least add support for, Qt5. As long as MacPorts doesn't provide a > mechanism to signal a port name change and thus let user installations go > from, say, QtCurve to qt4-QtCurve automatically, I don't see another solution > of the kind I've adopted in my 2 proposals (Charm and QtCurve). Like other explained, you could use replaced_by to change the port name, so you could have both qt4-qtcurve and qt5-qtcurve for example, with qtcurve being automatically replaced by qt4-curve. My view about prefix vs. suffix: I have a somewhat strong feeling against using the prefix for Qt applications. I would use a prefix for ports and modules that are strictly related to Qt, for example qt5-widgets, qt5-webkit, qt5-sensors, qt5-bluetooth, qt5-doc, ... (basically anything that could be downloaded from the Nokia website, maybe a bit more), but I would never use something like qt5-gnuplot or qt5-wireshark. Maybe gnuplot-qt5 if it has to be, but it feels just wrong to me to prefix random applications that only uses Qt. And honestly I would prefer to keep using "gnuplot +qt5" rather than a separate port. This might be different for modules/libraries/building blocks that other applications need where you actually need to provide both versions. At least until all other dependents upgrade to Qt 5. I don't know what exactly QtCurve does, so I find it a bit difficult to judge to which category it belongs and whether a prefix is justified in that case. But again, that's just my view. Mojca PS: The only reason why I didn't switch to Qt5 in one of my ports was because Qt4 and Qt5 still conflict and I cannot afford to make my port Qt5-only, thus conflicting with many other ports. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: qt5- prefix
On Jan 16, 2015, at 5:09 PM, René J.V. Bertin wrote: > On Friday January 16 2015 16:43:45 Lawrence Velázquez wrote: > >> A buildslave will not provide archives that a user could not compile >> themselves. > > So the buildslaves for 10.6 run 10.6 themselves? Yes. > Does each buildslave build with the minimal OS version set to the target OS > version, and use the "current OS" SDK? As far as I know, the buildslaves more or less do a `port install` with the default MacPorts configuration; they don't do anything out of the ordinary. So most C-language ports are built for deployment on the host operating system. > Out of curiosity: If the binary packages for 10.7 are not built against the > 10.7 SDK, it ought to be possible to rename them and put them in the right > download directory on 10.6 and thus trick MacPorts into installing them, > which should give working apps, no? Theoretically yes, but the Lion archives are intended to be deployed on Lion. If any of them were built to be deployed on 10.6, it was probably unintentional. vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: qt5- prefix
On Friday January 16 2015 16:43:45 Lawrence Velázquez wrote: > > To be equally blunt: the user is always right. > > This is not our general attitude towards this matter. And I rarely work on ports that I don't use or intend to use myself, so ... :) > We prefer users not be allowed to choose their dependencies unless there's a > good reason, such as API/ABI incompatibilities, or if the dependencies would > take a very long time to build. Both of which apply to Qt. > A buildslave will not provide archives that a user could not compile > themselves. So the buildslaves for 10.6 run 10.6 themselves? Does each buildslave build with the minimal OS version set to the target OS version, and use the "current OS" SDK? (I'm pretty sure I've seen the minimal OS version set to 10.6 when building Qt5 this week, but not the SDK of course. In fact, I had to rename the 10.10 SDK Xcode 6.1 dumped on me to NOT build against that one... on 10.9). Out of curiosity: If the binary packages for 10.7 are not built against the 10.7 SDK, it ought to be possible to rename them and put them in the right download directory on 10.6 and thus trick MacPorts into installing them, which should give working apps, no? R. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: qt5- prefix
On Jan 16, 2015, at 4:29 PM, René J.V. Bertin wrote: > Bit rot, in source code? Not literal rot, but as the operating system and developer tools move on, it gets more and more difficult to maintain older software that is not under active development. > I frankly don't see any reason to prefer subports over independent ports; I'm > pretty sure the replaced_by/obsolete functionality will work fine for > subports too. Subports are just an organizational tool. Once in the index, the ports created with the `subport` command are basically equivalent to those created at the "top level" of the portfiles. Replacing subports works fine. >> To be blunt, tough. If a user really wants > > To be equally blunt: the user is always right. This is not our general attitude towards this matter. >> portfile for themselves. The port maintainer >> ought to pick one variant as the default. My > > Picking a default isn't the same as imposing it, to the point of throwing in > an additional Qt install. > > Anyway, that's up to port maintainers to decide for their ports, and not to > be imposed as dogma by MacPorts, IMHO. We prefer users not be allowed to choose their dependencies unless there's a good reason, such as API/ABI incompatibilities, or if the dependencies would take a very long time to build. (For instance, if llvm-* didn't take so long to build, we'd probably make ld64 and cctools rely on a single version instead of providing variants.) > Building on 10.6 is (neigh) impossible, but you can build on 10.7+ (or just > 10.7?) with backward compatibility for 10.6, and then deploy to 10.6 . I've > tested that by using Digia's Qt5 installed on a 10.9 VM and then copying the > install dir to my 10.6.8 host. Works fine. > > I'm not sure how that'd work out for the buildbots though ... A buildslave will not provide archives that a user could not compile themselves. vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: qt5- prefix
On Friday January 16 2015 14:52:35 Craig Treleaven wrote:
> The replaced_by keyword (and obsolete PortGroup) support what you've
> described:
>
> https://guide.macports.org/#development.practices.rename-replace-port
Interesting.
> Qt4 (or just bit rot) are going to push projects
Bit rot, in source code? If Qt3's continued survival is any indication, Qt4
will continue to see some form of maintenance for a long time.
> to give up on Qt4. IOW, sub-ports or variants
> for Qt4/Qt5 should be unusual exceptions rather
> than the norm. Pick the right time and make the
I frankly don't see any reason to prefer subports over independent ports; I'm
pretty sure the replaced_by/obsolete functionality will work fine for subports
too.
> move. Use a -devel port if experimentation is
> required in the interim.
In fact, -devel ports are commonly used to test a newer version of the port
itself, not of some API it depends on.
Besides, there's precedence from the GTk, Python and Perl ports.
> >version-agnostic Qt PortGroup that could even
> >include the version-specific PortGroup, though.
>
> Could you clarify what you mean here?
Forget it, that was a little too wild an idea. I thought one could come up with
some kind of common denominator PortGroup to ease the transition, but if so I
need to think it over more.
> >If you accept that detection of the installed
> >version is done automatically, yes. But when you
> >do that, how do you handle the case the user has
> >both Qt versions installed? Even if you as a
> >port developer (knowing the port and all) have a
> >preference, the user might not agree.
>
> To be blunt, tough. If a user really wants
To be equally blunt: the user is always right.
> portfile for themselves. The port maintainer
> ought to pick one variant as the default. My
Picking a default isn't the same as imposing it, to the point of throwing in an
additional Qt install.
Anyway, that's up to port maintainers to decide for their ports, and not to be
imposed as dogma by MacPorts, IMHO.
> I see the Qt5 supports OS X 10.7 and later ('best
> efforts' for 10.6, if I read it right):
Building on 10.6 is (neigh) impossible, but you can build on 10.7+ (or just
10.7?) with backward compatibility for 10.6, and then deploy to 10.6 . I've
tested that by using Digia's Qt5 installed on a 10.9 VM and then copying the
install dir to my 10.6.8 host. Works fine.
I'm not sure how that'd work out for the buildbots though ...
> For some ports, if the maintainer wants to keep
> it running on old OS X versions, they might use
> Qt4 for older OS environments and Qt5 for newer.
> Not a variant, just do the right thing in the
> environment.
R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: qt5- prefix
At 4:11 PM +0100 1/16/15, René J.V. Bertin wrote:
On Friday January 16 2015 08:27:18 Craig Treleaven wrote:
IIUC, your post isn't related to Qt4/5
co-installability, but to how Qt-specific
versions of ports distinguish themselves.
https://trac.macports.org/ticket/46575
If I understand correctly, Charm will create subports ala:
qt5-charm
charm
Yes.
Is this supposed to be a model for going forward?
No idea.
I only picked the qt5- prefix because there's
some precedence, though admittedly Qt Creator
has a qt4- prefix for the Qt4 version.
Similarly, GTk ports indeed have -gtk2 or -gtk3
suffixes ... though there it might be more usual
to have a GTk2 dependency be the implicit
default.
I find the "qt5-" prefix objectionable.
Frankly, I don't know and I don't have a real
preference: I'm open to suggestions.
We do have the likely situation where more and
more ports will transition to, or at least add
support for, Qt5. As long as MacPorts doesn't
provide a mechanism to signal a port name change
and thus let user installations go from, say,
QtCurve to qt4-QtCurve automatically, I don't
see another solution of the kind I've adopted in
my 2 proposals (Charm and QtCurve).
The replaced_by keyword (and obsolete PortGroup) support what you've described:
https://guide.macports.org/#development.practices.rename-replace-port
> Going forward, I believe we will have the following cases:
1) Projects that work with Qt4 but not Qt5
2) Projects that work with Qt5 but not Qt4
3) Projects that work with either Qt4 or Qt5 but differ in non-trivial ways
4) Projects that work with the same with Qt4 or Qt5
Assuming we have co-installable Qt4 and Qt5 via
MacPorts, cases 1), 2) and 4) are
straightforward: 'port:' style dependencies for
1) and 2) and 'path:' style for 4).
AFAIC, case 4) ports will either impose a choice
(port: style dependency) or leave choice to the
user, as I did with Charm.
As port maintainers, I believe we _should_ make
choices on behalf of users. Case by case,
revision by revision, if there is a choice
between Qt4 and Qt5, the port maintainer should
evaluating whether to stay with Qt4 or jump to 5.
At some point, I suspect security problems with
Qt4 (or just bit rot) are going to push projects
to give up on Qt4. IOW, sub-ports or variants
for Qt4/Qt5 should be unusual exceptions rather
than the norm. Pick the right time and make the
move. Use a -devel port if experimentation is
required in the interim.
There is something to say with providing a
version-agnostic Qt PortGroup that could even
include the version-specific PortGroup, though.
Could you clarify what you mean here?
> OTOH, there might be rare cases where users might
need to choose between the Qt4 version (more
compatible, say) and a Qt5 version (new
features). Qt4/Qt5 variants would then be
appropriate.
If you accept that detection of the installed
version is done automatically, yes. But when you
do that, how do you handle the case the user has
both Qt versions installed? Even if you as a
port developer (knowing the port and all) have a
preference, the user might not agree.
To be blunt, tough. If a user really wants
another configuration, they can create a modified
portfile for themselves. The port maintainer
ought to pick one variant as the default. My
impression is that the vast majority of installs
use only the default variants. We shouldn't shy
away from the doing the right thing for (the
majority of) our users.
I see the Qt5 supports OS X 10.7 and later ('best
efforts' for 10.6, if I read it right):
http://doc.qt.io/qt-5/osx.html
For some ports, if the maintainer wants to keep
it running on old OS X versions, they might use
Qt4 for older OS environments and Qt5 for newer.
Not a variant, just do the right thing in the
environment.
Craig
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [131354] trunk/dports/gis/cgal/Portfile
>> -master_siteshttps://gforge.inria.fr/frs/download.php/34150 >> +master_sites >> https://gforge.inria.fr/frs/download.php/file/34403/CGAL-4.5.1.tar.bz2 > > master_sites should be the directory the distfile is in, and should not > include the actual distfile name. > master_siteshttps://gforge.inria.fr/frs/download.php/file/34403/ Done Ryan. Thanks. But for whatever reason, at the time I did update the Portfile, it seemed the website interface for CGAL fetched the file from this very directory. Hopefully the shortened form works, too. Thanks for pointing it out. Vincent ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: qt5- prefix
On Friday January 16 2015 08:27:18 Craig Treleaven wrote: IIUC, your post isn't related to Qt4/5 co-installability, but to how Qt-specific versions of ports distinguish themselves. > https://trac.macports.org/ticket/46575 > > If I understand correctly, Charm will create subports ala: > > qt5-charm > charm Yes. > Is this supposed to be a model for going forward? No idea. I only picked the qt5- prefix because there's some precedence, though admittedly Qt Creator has a qt4- prefix for the Qt4 version. Similarly, GTk ports indeed have -gtk2 or -gtk3 suffixes ... though there it might be more usual to have a GTk2 dependency be the implicit default. > I find the "qt5-" prefix objectionable. Frankly, I don't know and I don't have a real preference: I'm open to suggestions. We do have the likely situation where more and more ports will transition to, or at least add support for, Qt5. As long as MacPorts doesn't provide a mechanism to signal a port name change and thus let user installations go from, say, QtCurve to qt4-QtCurve automatically, I don't see another solution of the kind I've adopted in my 2 proposals (Charm and QtCurve). R. > Going forward, I believe we will have the following cases: > 1) Projects that work with Qt4 but not Qt5 > 2) Projects that work with Qt5 but not Qt4 > 3) Projects that work with either Qt4 or Qt5 but differ in non-trivial ways > 4) Projects that work with the same with Qt4 or Qt5 > > Assuming we have co-installable Qt4 and Qt5 via > MacPorts, cases 1), 2) and 4) are > straightforward: 'port:' style dependencies for > 1) and 2) and 'path:' style for 4). AFAIC, case 4) ports will either impose a choice (port: style dependency) or leave choice to the user, as I did with Charm. There is something to say with providing a version-agnostic Qt PortGroup that could even include the version-specific PortGroup, though. > OTOH, there might be rare cases where users might > need to choose between the Qt4 version (more > compatible, say) and a Qt5 version (new > features). Qt4/Qt5 variants would then be > appropriate. If you accept that detection of the installed version is done automatically, yes. But when you do that, how do you handle the case the user has both Qt versions installed? Even if you as a port developer (knowing the port and all) have a preference, the user might not agree. R. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: co-installable qt4-mac and qt5-mac step1 : qt4-mac +concurrent
At 10:56 AM +0100 12/20/14, René J.V. Bertin wrote:
On Saturday December 20 2014 17:44:30 Ian Wadham wrote:
Morning Ian!
It is a great start !!! Thanks very much René!
You are welcome (and I and the rest of us...) Someone had to do this...
I was hoping a few other MacPorts/KDE-Mac users
could try this, esp. those doing work on Qt5/KF5
...
One test that could indicate whether indeed this
allows concurrency is to install
qt4-mac+concurrent (*not* qt4-mac-transitional)
and the current, unmodified qt5-mac .
I think that ought to work.
a) Traditionally you can install new or
development versions of Qt "somewhere else"
and point to your test or development
version via environment variable $QTDIR.
Does this presuppose a fixed hierarchy
of directories and names under $QTDIR?
If so, changing that hierarchy may cause problems.
I think that nowadays the QTDIR "trick" is
mostly to use a test version in a different tree
with applications that were already linked to
your usual version. If so, that means that QTDIR
must point to a complete directory and as long
as that's the case you should be fine.
QTDIR is not (no longer?) required for running.
b) Shifting Qt libraries from ${prefix}/lib
to ${prefix}/libexec/${qt_name}/lib might be
a "no-op". In the lib subdir
(/opt/local/lib on my system), Qt libraries are
installed
as links. For example, libQtCore.dylib,
libQtCore.4.dylib, libQtCore.4.8.dylib and
libQtCore.4.8.6.dylib all point to
/opt/local/Library/Frameworks/QtCore.framework/QtCore,
which in turn points to
Versions/4/QtCore and THAT is actually a file
described as
Versions/4/QtCore: Mach-O 64-bit x86_64
dynamically linked shared library.
Maybe I am missing something.
Yes, you are :) Those frameworks have been moved too.
qt4-mac and qt5-mac use a sneaky trick to
provide a combined framework and traditional
build, based on the fact that an OS X framework
is nothing but a shared library (without the
usual extension) combined with all associated
stuff bundled in a specific way. You can get
very close by using
--prefix=/Library/Frameworks/foo/Versions/${MAJOR_VERSION}
and then setting up a couple of symlinks to
disclose certain things a bit more directly.
So symlinking framework binaries as you saw
makes the link editor can find them ... it
already knows how to handle them.
All that to say that no, the qt_libs_dir shift
is not a no-op. Try it :) and if you didn't
install qt4-mac-transitional in the same command
you'll get errors from rev-upgrade. Or else
you'll see that re-built Qt or KDE applications
now link to stuff in /opt/local/libexec/qt4 .
Related to the proposed Charm port:
https://trac.macports.org/ticket/46575
If I understand correctly, Charm will create subports ala:
qt5-charm
charm
Is this supposed to be a model for going forward?
I find the "qt5-" prefix objectionable.
Going forward, I believe we will have the following cases:
1) Projects that work with Qt4 but not Qt5
2) Projects that work with Qt5 but not Qt4
3) Projects that work with either Qt4 or Qt5 but differ in non-trivial ways
4) Projects that work with the same with Qt4 or Qt5
Assuming we have co-installable Qt4 and Qt5 via
MacPorts, cases 1), 2) and 4) are
straightforward: 'port:' style dependencies for
1) and 2) and 'path:' style for 4).
In case 3), I think the upstream development plan
is important. If upstream is moving to
supporting Qt5 and the current differences are
due to incomplete support, I think it would be
more appropriate to create a '-devel' version of
the port until the Qt5 conversion is complete.
OTOH, there might be rare cases where users might
need to choose between the Qt4 version (more
compatible, say) and a Qt5 version (new
features). Qt4/Qt5 variants would then be
appropriate.
FWIW, the project I'm most concerned with,
MythTV, has had a working build with Qt5 for a
long time and is encouraging testing but it is
not recommended for casual users. AIUI, it was
not particularly difficult to add Qt5 support
even though Myth uses Qt extensively for user
interface (including video rendering) and OS
abstraction. When upstream is closer to another
release (0.28), I plan to create a -devel version
using Qt5. Barring show-stoppers, I expect to
transition to Qt5 exclusively.
Craig
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
