Re: All KDE ports need a major revbump, due to recent changes to qt4-mac

[Michael Dickens]

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 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, René J. V. Bertin wrote:
> 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?
___
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

[René J . V . Bertin]

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@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Showing the full ./configure command also with -v, not just with -d

[Christopher Jones]

> On 30 Oct 2015, at 16:41, Sean Farley  wrote:
> 
> 
> Mojca Miklavec mailto:mo...@macports.org>> writes:
> 
>> Hi,
>> 
>> I would really appreciate it if I could see the complete configure
>> command already in verbose mode (port -v configure), not just debug
>> mode (port -d configure). The same applies to build/make, but usually
>> that one doesn't contain so much extra parameters.
>> 
>> The command "port -d ..." is wy too verbose, hardly useful for any
>> port maintainer, and it's sometimes very difficult to find the
>> relevant output, while "port -v ..." seems just perfect for showing
>> that. We already get hundreds of lines of output during "./configure",
>> so one extra line would bring a lot of benefit with hardly any
>> penalty.
>> 
>> (Environmental variables would also be very helpful, even though I
>> wouldn't know whether they make more sense in verbose or debug mode. I
>> would like to see them in verbose mode as well, but it's still ok if
>> they are more hidden than the configure command itself.)
> 
> I have wanted this for a very long time!

same here. But please, if enabled, do so for all build systems (for instance 
cmake).

Chris
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org 
> https://lists.macosforge.org/mailman/listinfo/macports-dev 
> 


smime.p7s
Description: S/MIME cryptographic signature
___
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

[René J . V . Bertin]

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 managed to get qtscriptgenerator to build without patching 
any other ports, a bit to my surprise.

https://trac.macports.org/ticket/47204#comment:17

The main issue appeared to be that qtsg does not only use qmake to find 
components, but also includes its own internal search logic which is based in 
part on the obsolete QTDIR env. variable.

Debian/Ubuntu exploit that by setting QTDIR=/usr/include/qt4 which is obviously 
not at all what QTDIR was once intended for. I didn't dare to remove the QTDIR 
setting from the Qt4 PortGroup at this point, so I unset it in the qtsg 
Portfile.
I then introduce a patch to generator/main.h which queries a novel QTFRAMEWORKS 
env.var (set in the qtsg Portfile) or else falls back to a hardcoded copy of 
${qt_frameworks_dir}. That fallback appears to be redundant because the 
generator is not installed (which I wasn't sure about when I wrote the patch).
An additional few lines that add ${prefix}/include/phonon allow the phonon code 
to be compiled. They might not be required with a patched phonon mkspec file, 
but 
my current solution is much less likely to introduce side-effects.

I'll have to check some other time whether the 2 additional patchfiles I added 
are actually required, but I won't be offended if someone beats me to it :)

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

[René J . V . Bertin]

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 libraries and/or

Concretely, what's the change you make to qt_phonon.pri?

Anyway, is your Qt4 PortGroup still setting QTDIR? I think the issue I'm seeing 
is due to that (in fact, I'm sure, from looking at generator/main.h).

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

[Michael Dickens]

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 
> > and
> > rebuild I still get the same error.
> 

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 libraries and/or
frameworks are correctly found and processed by the qtscriptgenerator
code.
{{{
:info:build cd qtscript_phonon/ && /opt/local/libexec/qt4/bin/qmake
/opt/local/var/macports/build/_Users_Shared_source_MacPorts_trunk_dports_devel_qtscriptgenerator/qtscriptgenerator/work/qtscriptgenerator-src-0.2.0/qtbindings/qtscript_phonon/qtscript_phonon.pro
-o Makefile
:info:build Project MESSAGE: In: mkspecs/modules/qt_phonon.pri
:info:build WARNING:
/opt/local/var/macports/build/_Users_Shared_source_MacPorts_trunk_dports_devel_qtscriptgenerator/qtscriptgenerator/work/qtscriptgenerator-src-0.2.0/qtbindings/qtscript_phonon/qtscript_phonon.pro:5:
Unable to find file for inclusion
/opt/local/var/macports/build/_Users_Shared_source_MacPorts_trunk_dports_devel_qtscriptgenerator/qtscriptgenerator/work/qtscriptgenerator-src-0.2.0/generated_cpp/com_trolltech_qt_phonon/com_trolltech_qt_phonon.pri
:info:build Project MESSAGE: qtAddLibrary: LIBS before phonon is
:info:build Project MESSAGE: qtAddLibrary: INCLUDEPATH before phonon is
/opt/local/libexec/qt4/include .
/opt/local/libexec/qt4/include/phonon_compat
:info:build Project MESSAGE: qtAddLibrary: QMAKE_LFLAGS before phonon is
-headerpad_max_install_names -arch x86_64 -Xarch_x86_64
-mmacosx-version-min=10.11
:info:build Project MESSAGE: qtAddLibrary: all frameworks is
-F/opt/local/libexec/qt4/Library/Frameworks -F/opt/local/libexec/qt4/lib
:info:build Project MESSAGE: qtAddLibrary: this frmwrk_dir is
-F/opt/local/libexec/qt4/Library/Frameworks
:info:build Project MESSAGE: qtAddLibrary: this frmwrk_path is
/opt/local/libexec/qt4/Library/Frameworks
:info:build Project MESSAGE: qtAddLibrary: this frmwrk_dir is
-F/opt/local/libexec/qt4/lib
:info:build Project MESSAGE: qtAddLibrary: this frmwrk_path is
/opt/local/libexec/qt4/lib
:info:build Project MESSAGE: qtAddLibrary: looking for framework phonon
in directory /opt/local/libexec/qt4/Library/Frameworks
:info:build Project MESSAGE: qtAddLibrary: looking for framework phonon
in directory /opt/local/libexec/qt4/lib
:info:build Project MESSAGE: qtAddLibrary: looking for framework phonon
in directory /opt/local/libexec/qt4/Library/Frameworks
:info:build Project MESSAGE: qtAddLibrary: looking for framework phonon
in directory /opt/local/libexec/qt4/lib
:info:build Project MESSAGE: qtAddLibrary: looking for framework phonon
in directory /opt/local/libexec/qt4/lib
:info:build Project MESSAGE: qtAddLibrary: all library paths is
-L/opt/local/libexec/qt4/lib
:info:build Project MESSAGE: qtAddLibrary: this lib_dir is
-L/opt/local/libexec/qt4/lib
:info:build Project MESSAGE: qtAddLibrary: this lib_path is
/opt/local/libexec/qt4/lib
:info:build Project MESSAGE: qtAddLibrary: looking for library phonon in
directory /opt/local/libexec/qt4/lib
:info:build Project MESSAGE: qtAddLibrary: looking for library phonon in
directory /opt/local/libexec/qt4/lib
:info:build Project MESSAGE: qtAddLibrary: looking for library phonon in
directory /opt/local/libexec/qt4/lib
:info:build Project MESSAGE: WARNING: Could not find library or
framework phonon in the current known search directories; assuming a
default library.
:info:build Project MESSAGE: qtAddLibrary: LIBS after phonon is now
-F/opt/local/libexec/qt4/Library/Frameworks -F/opt/local/libexec/qt4/lib
-L/opt/local/libexec/qt4/lib -lphonon
:info:build Project MESSAGE: qtAddLibrary: INCLUDEPATH after phonon is
now . /opt/local/libexec/qt4/include/phonon_compat
/opt/local/libexec/qt4/include/phonon /opt/local/libexec/qt4/include
:info:build Project MESSAGE: qtAddLibrary: QMAKE_LFLAGS after phonon is
now -headerpad_max_install_names -arch x86_64 -Xarch_x86_64
-mmacosx-version-min=10.11
[snip]
:info:build WARNING: Failure to find:
../../generated_cpp/com_trolltech_qt_phonon/plugin.cpp
:info:build cd qtscript_phonon/ &&
/Applications/Xcode.app/Contents/Developer/usr/bin/make -f Makefile all
:info:build make[2]: Entering directory
`/opt/local/var/macports/build/_Users_Shared_source_MacPorts_trunk_dports_devel_qtscriptgenerator/qtscriptgenerator/work/qtscriptgenerator-src-0.2.0/qtbindings/qtscript_phonon'
:info:build make[2]: *** No rule to make target
`../../generated_cpp/com_trolltech_qt_phonon/plugin.cpp', needed by
`plugin.o'.  Stop.
:info:build make[2]: Leaving directory
`/opt/local/var/macports/build/_Users_Shared_source_MacPorts_trunk_dports_devel_qtscriptgenerator/qtscriptgenerator/wor

Re: Showing the full ./configure command also with -v, not just with -d

[Sean Farley]

Mojca Miklavec  writes:

> Hi,
>
> I would really appreciate it if I could see the complete configure
> command already in verbose mode (port -v configure), not just debug
> mode (port -d configure). The same applies to build/make, but usually
> that one doesn't contain so much extra parameters.
>
> The command "port -d ..." is wy too verbose, hardly useful for any
> port maintainer, and it's sometimes very difficult to find the
> relevant output, while "port -v ..." seems just perfect for showing
> that. We already get hundreds of lines of output during "./configure",
> so one extra line would bring a lot of benefit with hardly any
> penalty.
>
> (Environmental variables would also be very helpful, even though I
> wouldn't know whether they make more sense in verbose or debug mode. I
> would like to see them in verbose mode as well, but it's still ok if
> they are more hidden than the configure command itself.)

I have wanted this for a very long time!
___
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

[René J . V . Bertin]

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 end goes beyond phonon:

%> (cd `port work qtscriptgenerator`/qtscript*/qtbindings ; wmake --MP -k)
cd qtscript_core/ && /Applications/Xcode.app/Contents/Developer/usr/bin/make -f 
Makefile 
make[1]: Nothing to be done for `first'.
cd qtscript_gui/ && /Applications/Xcode.app/Contents/Developer/usr/bin/make -f 
Makefile 
make[1]: *** No rule to make target 
`../../generated_cpp/com_trolltech_qt_gui/plugin.cpp', needed by `plugin.o'.
make[1]: Target `first' not remade because of errors.
make: *** [sub-qtscript_gui-make_default] Error 2
cd qtscript_network/ && /Applications/Xcode.app/Contents/Developer/usr/bin/make 
-f Makefile 
make[1]: *** No rule to make target 
`../../generated_cpp/com_trolltech_qt_network/plugin.cpp', needed by `plugin.o'.
make[1]: Target `first' not remade because of errors.
make: *** [sub-qtscript_network-make_default] Error 2
cd qtscript_opengl/ && /Applications/Xcode.app/Contents/Developer/usr/bin/make -
f Makefile 
make[1]: *** No rule to make target 
`../../generated_cpp/com_trolltech_qt_opengl/plugin.cpp', needed by `plugin.o'.
make[1]: Target `first' not remade because of errors.
make: *** [sub-qtscript_opengl-make_default] Error 2
cd qtscript_sql/ && /Applications/Xcode.app/Contents/Developer/usr/bin/make -f 
Makefile 
make[1]: *** No rule to make target 
`../../generated_cpp/com_trolltech_qt_sql/plugin.cpp', needed by `plugin.o'.
make[1]: Target `first' not remade because of errors.
make: *** [sub-qtscript_sql-make_default] Error 2
cd qtscript_svg/ && /Applications/Xcode.app/Contents/Developer/usr/bin/make -f 
Makefile 
make[1]: *** No rule to make target 
`../../generated_cpp/com_trolltech_qt_svg/plugin.cpp', needed by `plugin.o'.
make[1]: Target `first' not remade because of errors.
make: *** [sub-qtscript_svg-make_default] Error 2
cd qtscript_xml/ && /Applications/Xcode.app/Contents/Developer/usr/bin/make -f 
Makefile 
make[1]: *** No rule to make target 
`../../generated_cpp/com_trolltech_qt_xml/plugin.cpp', needed by `plugin.o'.
make[1]: Target `first' not remade because of errors.
make: *** [sub-qtscript_xml-make_default] Error 2
cd qtscript_phonon/ && /Applications/Xcode.app/Contents/Developer/usr/bin/make -
f Makefile 
make[1]: *** No rule to make target 
`../../generated_cpp/com_trolltech_qt_phonon/plugin.cpp', needed by `plugin.o'.
make[1]: Target `first' not remade because of errors.
make: *** [sub-qtscript_phonon-make_default] Error 2
cd qtscript_webkit/ && /Applications/Xcode.app/Contents/Developer/usr/bin/make -
f Makefile 
make[1]: *** No rule to make target 
`../../generated_cpp/com_trolltech_qt_webkit/plugin.cpp', needed by `plugin.o'.
make[1]: Target `first' not remade because of errors.
make: *** [sub-qtscript_webkit-make_default] Error 2
cd qtscript_xmlpatterns/ && 
/Applications/Xcode.app/Contents/Developer/usr/bin/make -f Makefile 
make[1]: *** No rule to make target 
`../../generated_cpp/com_trolltech_qt_xmlpatterns/plugin.cpp', needed by 
`plugin.o'.
make[1]: Target `first' not remade because of errors.
make: *** [sub-qtscript_xmlpatterns-make_default] Error 2
cd qtscript_uitools/ && /Applications/Xcode.app/Contents/Developer/usr/bin/make 
-f Makefile 
make[1]: *** No rule to make target 
`../../generated_cpp/com_trolltech_qt_uitools/plugin.cpp', needed by `plugin.o'.
make[1]: Target `first' not remade because of errors.
make: *** [sub-qtscript_uitools-make_default] Error 2


(`wmake` is a wrapper for make that sets the environment like `port` does when 
invoked with `--MP`)

For me, the issue appears to be that the qtsg build system expects to find the 
Qt headers in ${prefix}/libexec/qt4/include/QtFoo.framework/Headers , which is 
to me suggests that it has an issue with a frameworks build. When I populate 
that include directory with symlinks to the frameworks, the build goes further, 
but aborts with errors like

Undefined symbols for architecture x86_64:
  "qtscript_initialize_com_trolltech_qt_opengl_bindings(QScriptValue&)", 
referenced from:
  com_trolltech_qt_opengl_ScriptPlugin::initialize(QString const&, 
QScriptEngine*) in plugin.o
ld: symbol(s) not found for architecture x86_64


___
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]

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 the dependency is
there. It does not work with ffmpeg-devel, so it won't build for me. I
really wish the ffmpeg folks would decide where to put their headers &
not change them.

py*-pyqt4 doesn't actually use qmake to determine where phonon is
located; it does that for just the Qt* libraries / frameworks. It uses
some other magic to determine info for phonon. MacPorts sets CFLAGS to
include "-I${prefix}/include" and LDFLAGS to include "-L${prefix}/lib",
so it's no great surprise that phonon is being found.

qtscriptgenerator uses 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" 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 qmake and require
> > phonon? I'd like to test out this theory before pushing changes into
> > phonon. - MLD
> 
> I was under the impression you knew better than I, but there's the list
> of all ports that declare a dependency on phonon in their Portfile
> (excluding qt4-mac and qt4-x11):
> 
> %> fgrep -il qmake `fgrep -il phonon -R
> /opt/local/var/macports/sources/svn.macports.org/trunk/dports/
> --include=Portfile `
> /opt/local/var/macports/sources/svn.macports.org/trunk/dports/devel/qtscriptgenerator/Portfile
> /opt/local/var/macports/sources/svn.macports.org/trunk/dports/office/goldendict/Portfile
> /opt/local/var/macports/sources/svn.macports.org/trunk/dports/python/py-pyqt4/Portfile
> 
> 
> I checked again this morning: goldendict builds though I can see no trace
> of it actually depending on phonon in the build log nor in the resulting
> binary. I have py27-pyqt4+phonon and py34-pyqt4 installed, and as far as
> I can tell those are fully functional:
> 
> %> otool -L
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PyQt4/phonon.so
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PyQt4/phonon.so:
> /opt/local/lib/libphonon.4.dylib (compatibility version 4.4.0,
> current version 4.8.3)
> 
> /opt/local/libexec/qt4/Library/Frameworks/QtGui.framework/Versions/4/QtGui
> (compatibility version 4.8.0, current version 4.8.7)
> 
> /opt/local/libexec/qt4/Library/Frameworks/QtCore.framework/Versions/4/QtCore
> (compatibility version 4.8.0, current version 4.8.7)
> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
> (compatibility version 45.0.0, current version 1265.21.0)
> /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
> version 120.0.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 1197.1.1)
> 
> R
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
___
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

[René J . V . Bertin]

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 difference either.

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

[René J . V . Bertin]

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 qmake and require
> phonon? I'd like to test out this theory before pushing changes into
> phonon. - MLD

I was under the impression you knew better than I, but there's the list of all 
ports that declare a dependency on phonon in their Portfile (excluding qt4-mac 
and qt4-x11):

%> fgrep -il qmake `fgrep -il phonon -R 
/opt/local/var/macports/sources/svn.macports.org/trunk/dports/ 
--include=Portfile `
/opt/local/var/macports/sources/svn.macports.org/trunk/dports/devel/qtscriptgenerator/Portfile
/opt/local/var/macports/sources/svn.macports.org/trunk/dports/office/goldendict/Portfile
/opt/local/var/macports/sources/svn.macports.org/trunk/dports/python/py-pyqt4/Portfile


I checked again this morning: goldendict builds though I can see no trace of it 
actually depending on phonon in the build log nor in the resulting binary. I 
have py27-pyqt4+phonon and py34-pyqt4 installed, and as far as I can tell those 
are fully functional:

%> otool -L 
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PyQt4/phonon.so
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PyQt4/phonon.so:
/opt/local/lib/libphonon.4.dylib (compatibility version 4.4.0, current 
version 4.8.3)

/opt/local/libexec/qt4/Library/Frameworks/QtGui.framework/Versions/4/QtGui 
(compatibility version 4.8.0, current version 4.8.7)

/opt/local/libexec/qt4/Library/Frameworks/QtCore.framework/Versions/4/QtCore 
(compatibility version 4.8.0, current version 4.8.7)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 
(compatibility version 45.0.0, current version 1265.21.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 
120.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 1197.1.1)

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

[Michael Dickens]

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 via qmake. But, even with that addition
qtscriptgenerator still does not build (at least to 10.11 latest
everything). As I said, I'm looking into it. My read of the qmake /
phonon combo is that the only way using qmake to find phonon will work
is to make sure that either (1) "LIBS *= -L${prefix}/lib" is in place
before doing "CONFIG *= phonon"; or (2) including a project that sets
LIBS accordingly before adding in phonon. Otherwise, qmake will not look
in ${prefix}/lib for phonon. What other projects use qmake and require
phonon? I'd like to test out this theory before pushing changes into
phonon. - MLD

On Fri, Oct 30, 2015, at 05:33 AM, René J. V. Bertin wrote:
> The difference here is that QCA provides hooks to install that way, or at
> least 
> to indicate it where the various Qt components are installed. Phonon
> doesn't 
> AFAIK (and port:phonon certainly doesn't seem to add them).
> 
> I have been taking a look at qtscriptgenerator. It doesn't build indeed:
> 
> :info:build make[2]: *** No rule to make target 
> `../../generated_cpp/com_trolltech_qt_gui/plugin.cpp', needed by
> `plugin.o'.  
> Stop.
> 
> but that failure is not related to phonon. I do see an issue finding
> phonon, but 
> that appears to be more related to the fact that qtscriptgenerator looks
> for a 
> phonon *framework* (as opposed to a .dylib).
> BTW: I'll be trying the workaround described here: 
> https://code.google.com/p/qtscriptgenerator/issues/detail?id=39
> but I guess I should also check out why the build system looks for
> headers in 
> ${prefix}/libexec/qt4/include which doesn't exist in my layout.
> 
> Every other dependency of phonon I installed that uses qmake finds phonon
> just 
> fine with libphonon in ${prefix}/lib and the Qt4 frameworks in 
> ${prefix}/libexec/qt4/Library/Frameworks and .dylib symlinks pointing to
> those 
> framework binaries in ${prefix}/libexec/qt4/lib . And as far as I can
> tell, that 
> is *not* because I also have libqt symlinks in ${prefix}/lib (my qt4-mac-
> transitional subport).
> 
> Coming back to qtscriptgenerator: I'm looking at how Ubuntu gets it to
> build, 
> but the real question we have to ask for this port is whether it is worth
> the 
> effort trying to resurrect abandonware. The only dependent I could find
> is 
> amarok, and the application is built *without* qtscriptgenerator on
> Linux.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Showing the full ./configure command also with -v, not just with -d

[Mojca Miklavec]

Hi,

I would really appreciate it if I could see the complete configure
command already in verbose mode (port -v configure), not just debug
mode (port -d configure). The same applies to build/make, but usually
that one doesn't contain so much extra parameters.

The command "port -d ..." is wy too verbose, hardly useful for any
port maintainer, and it's sometimes very difficult to find the
relevant output, while "port -v ..." seems just perfect for showing
that. We already get hundreds of lines of output during "./configure",
so one extra line would bring a lot of benefit with hardly any
penalty.

(Environmental variables would also be very helpful, even though I
wouldn't know whether they make more sense in verbose or debug mode. I
would like to see them in verbose mode as well, but it's still ok if
they are more hidden than the configure command itself.)

What is your opinion about that? Could we change it?

Thank you,
Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Persistent copy of a [git] repository

[Mojca Miklavec]

Hi,

I'm reviving an old thread (fetch.type git & GitHub submodules).

I tried to make a proof-of-concept Portfile that is able to maintain a
persistent copy of the sources from a git repository:
https://trac.macports.org/attachment/ticket/16373/xchm.Portfile
https://trac.macports.org/ticket/16373#comment:32

The code should go elsewhere, but I would be grateful for feedback.
(Yes, we also need a solution for cvs, svn, hg, but let's start with
"the easiest" vcs type and see where we can get with that one.)

Mojca


On Wed, Mar 4, 2015 at 11:41 PM, Mojca Miklavec wrote:
> On Wed, Mar 4, 2015 at 10:53 PM, Rainer Müller wrote:
>> On 2015-03-04 22:27, Mojca Miklavec wrote:
 I agree with you, creating the distfiles from VCS would be possible.

 There could be a target to be run on 'port mirror' that downloads and
 creates a tarball if a non-default fetch.type is used. That alone would
 reduce multiple downloads and even makes port development faster.

 However, for end-users, there is the problem that we would need to
 distribute checksums for these tarballs (or rely on signatures only?).
>>>
>>> Of course we would have to distribute the checksums in that case, like
>>> for any other port. What exactly is considered a "problem" here?
>>
>> There are two options:
>>
>> a) the maintainer generates the tarball locally, uploads it to the main
>> mirror and also adds an additional checksum to the Portfile before
>> committing it
>
> No, this is certainly not what I had in mind.
>
> (But now that you mentioned it, it reminded me that we might sometimes
> want other complex strategies to fetch files, not just from VCS. Like
> wxPython where we only extract 400 kB out of a 50 MB file and it would
> be a waste to have to store and fetch all the 50 MB.)
>
>> b) tarballs are generated automatically on the server after the Portfile
>> was committed
>
> I was thinking of that option. (Tarballs would also be automatically
> generated on the user's machine straight from VCS if the file wouldn't
> exist on the mirror.)
>
>> I would prefer b) for the simple fact that this ensures that the
>> maintainer did not modify any of the files and would be closer to our
>> existing distfiles mirroring. The infrastructure changes would be small
>> if it can be integrated into what the existing 'port mirror' does.
>> However, checksums for the generated tarball are definitely not known at
>> the time the Portfile is committed.
>
> Why not? At least for GIT I can show you a trivial way to create a
> compressed file in a repeatable way. That way anyone would get the
> same checksums and the maintainer can easily add the checksums to the
> Portfile *before* committing.
>
> For other VCS it might be just slightly more complicated (I'm not so
> familiar with them), but probably not much. One just needs to make
> sure that all the files have reproducible/stable timestamps, including
> the tar file.
>
>> One solution for this would be to add an additional file in the port
>> directory after tarball generation that holds the checksums. Or, the
>> generated tarballs are also signed by the job that generated them. With
>> the signature it is possible to verify that this is the intended file
>> without distributing any additional checksum through other channels.
>
> That sounds way too complex.
>
>> In general, note that generating a tarball might include timestamps,
>> usernames, and other metadata.
>
> I just checked. I tried to generate a .tar.xz file on three different
> machines: one Mac OS X, two linux boxes. A different username and a
> different userid/groupid on every machine. And I got exactly the same
> checksum on all the three machines.
>
>> Generating it multiple times, locally by
>> the maintainer and once again on the server, will not always give the
>> same results. Although that would be the closest to what we do for
>> distfiles at the moment, combining the checksum in Portfile from a)
>> *and* the automatic generation on the server from b) is not possible.
>
> So what exactly did I do wrong when I managed to get the same
> checksums on three machines?
>
> Here's what I did:
> git clone  && cd 
> git archive  | xz > ../test.tar.xz
> md5 ../test.tar.xz
>
> I admit that I don't have enough experience to claim that this would
> generate the same checksums in all the possible scenarios that one can
> think of and all hardware that one can imagine, but I would be
> comfortable enough to speculate that in most cases there shouldn't be
> any difference on the user's Mac and the server.
>
> (I didn't test on servers in different timezones, but I would imagine
> that there must be a cure for that if that would result in some
> discrepancies. I also didn't think of zillion of other possible
> scenarios that could potentially spoil the game. I could imagine
> potential problems with repositories with "Makefile" and "makefile" in
> the same dir, resulting in different tarballs depending on wh

Re: All KDE ports need a major revbump, due to recent changes to qt4-mac

[René J . V . Bertin]

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 least 
to indicate it where the various Qt components are installed. Phonon doesn't 
AFAIK (and port:phonon certainly doesn't seem to add them).

I have been taking a look at qtscriptgenerator. It doesn't build indeed:

:info:build make[2]: *** No rule to make target 
`../../generated_cpp/com_trolltech_qt_gui/plugin.cpp', needed by `plugin.o'.  
Stop.

but that failure is not related to phonon. I do see an issue finding phonon, 
but 
that appears to be more related to the fact that qtscriptgenerator looks for a 
phonon *framework* (as opposed to a .dylib).
BTW: I'll be trying the workaround described here: 
https://code.google.com/p/qtscriptgenerator/issues/detail?id=39
but I guess I should also check out why the build system looks for headers in 
${prefix}/libexec/qt4/include which doesn't exist in my layout.

Every other dependency of phonon I installed that uses qmake finds phonon just 
fine with libphonon in ${prefix}/lib and the Qt4 frameworks in 
${prefix}/libexec/qt4/Library/Frameworks and .dylib symlinks pointing to those 
framework binaries in ${prefix}/libexec/qt4/lib . And as far as I can tell, 
that 
is *not* because I also have libqt symlinks in ${prefix}/lib (my qt4-mac-
transitional subport).

Coming back to qtscriptgenerator: I'm looking at how Ubuntu gets it to build, 
but the real question we have to ask for this port is whether it is worth the 
effort trying to resurrect abandonware. The only dependent I could find is 
amarok, and the application is built *without* qtscriptgenerator on Linux.

R.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev