On Saturday August 20 2016 23:11:30 Marko Käning wrote:
>did you see this post of mine back then?
>Wondering whether Rainer’s notes make sense...
Yes, I saw it, and IIRC I even reacted to it one way or another. So it was
Rainer who asked not to install all of Qt into its own prefix, just like I
I think I'm preparing to propose another revbump of the kde4 ports...
I've started continuing Marko's work on KF5 ports (the frameworks, for now, 2-3
a day :)). I don't know yet to what extent KF5 and KDE4 can co-exist (KDE4
applications *can* run on/under a KF5 desktop, so clearly some form of
René J. V. Bertin wrote:
> I'll be having a look myself too, this
> weekend. Debian also installs the generator and qs_eval binaries, btw, which
> suggests they might be useful if not needed.
Done; modifications pushed to my repo (github.com/RJVB/macstrop)
R.
___
Michael Dickens wrote:
> I'll try your patches & see what comes of it.
While you're at it and if you have time: Debian/Ubuntu apply a number of other
patches to the code to bring it up to date. They're in my port repository
(devel/qtscriptgenerator/files). I'll be having a look myself too, this
IIRC: "LIBS += FOO" adds FOO to LIBS without checking for duplicates,
while "*=" adds only after checking that FOO isn't already there.
And, yes, an INCLUDEPATH is also required. Just replicate what QCA does
in its mkspec file ("s/QCA/phonon/g"). That said ...
Further (from another part of this e
Michael Dickens wrote:
> correctly do "LIBS *=..." no matter where Phonon is installed. That
BTW, what's the difference with "LIBS += ..."?
Are you sure a matching INCLUDEPATH expression isn't required?
R.
___
macports-dev mailing list
macports-dev@li
Michael Dickens wrote:
> What I'm planning on doing for Phonon is modifying its mkspec file to
> correctly do "LIBS *=..." no matter where Phonon is installed. That
> seems like a nice robust solution.
Yes - as long as it doesn't introduce artefacts or other side-effects.
In the meantime, I mana
Michael Dickens wrote:
> Yes, I'm sure. Using the stock phonon mkspec file and commenting in some
> of the debug "#"s from qt_functions.prf, I see the following. Fixing
> qt_phonon.pri to "do the right thing" adds LIBS and INCLUDEPATH for
> wherever phonon is installed. All of the various QtFOO li
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 remove the typesystem_phonon line from generator.qrc
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 remove the typesystem_phonon line from generator.qrc and
> rebuild I still get the same error.
In fact, I think the issue on my e
What I'm planning on doing for Phonon is modifying its mkspec file to
correctly do "LIBS *=..." no matter where Phonon is installed. That
seems like a nice robust solution.
goldendict does not seem to actually use Phonon. It does use qmake, but
does no do "CONFIG *= phonon" anywhere. No idea why t
Michael Dickens wrote:
> The error you show below with qtscriptgenerator is because it does not
> find phonon
Are you sure? When I remove the typesystem_phonon line from generator.qrc and
rebuild I still get the same error.
Adding `LIBS += -L/opt/local/lib` to qtsg.pro doesn't make a differenc
Michael Dickens wrote:
> is to make sure that either (1) "LIBS *= -L${prefix}/lib" is in place
That seems like a small enough modification to qtscriptgenerator that if it
works is much preferable to "hiding" phonon under libexec/qt4 ...
> in ${prefix}/lib for phonon. What other projects use qma
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
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.
The difference here is that QCA provides hooks to install that way, or at
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
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
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
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
>
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
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 lib
> 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}/
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:
> Lib
Hello,
>>
>> No. All ports need to be revbumped (preferrably as soon as possible).
>> It's just that there were sooo many ports that revbumping all
>> could not be easily done by a single person.
>
> OK, thanks for reassuring me here.
Yes, I had started listing all the KDE ports which need
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
On Oct 27, 2015, at 6:07 PM, Marko Käning wrote:
>
> (When will Apple’s new admin have all those issues fixed I wonder…)
I am in communication with the admin and his manager about these issues. I
don't know how many details I should share right now but I hope to be able to
announce a solution
Hi Mojca,
On 27 Oct 2015, at 23:30 , Mojca Miklavec wrote:
> On Tue, Oct 27, 2015 at 11:03 PM, Marko Käning wrote:
>> Should we forget about revbumping everything and simply rely on that the
>> sanity of our users’ MacPorts installations
>> will be taken care of by rev-upgrade?
>
> No. All por
On Tue, Oct 27, 2015 at 11:03 PM, Marko Käning wrote:
> On 27 Oct 2015, at 22:48 , Marko Käning wrote:
>
>> Answering my own question now, at least partially, since a rev-upgrade just
>> gave me this much longer list:
>
> Should we forget about revbumping everything and simply rely on that the
>
On 27 Oct 2015, at 22:48 , Marko Käning wrote:
> Answering my own question now, at least partially, since a rev-upgrade just
> gave me this much longer list:
Should we forget about revbumping everything and simply rely on that the sanity
of our users’ MacPorts installations
will be taken care
Answering my own question now, at least partially, since a rev-upgrade just
gave me this much longer list:
---
---> Found 38 broken port(s), determining rebuild order
---> Rebuilding in order
qtscriptgenerator @0.2.0
kdenlive @0.9.10
kdiff3 @0.9.98
litecoin @0.8.7.4
cerv
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
31 matches
Mail list logo
