Question regarding +debug variant of KDE ports and qt4-mac
Hi Qt4-affine devs, on the kde-mac ML the question came up whether the necessity to install qt4-mac in its debug variant - when one simply needs KDE ports installed in their debug variant - is only due to MacPorts' way of handling port variants... If that's indeed the case, it may seem to be a good idea to replace in all KDE software ports the debug variant by a new variant - perhaps called debug_kde. In that case all ports depending on kdelibs4 would nicely manage their debug_kde variants amongst themselves and not mess with the standard-MacPorts debug variant at all anymore. The debug output of qt4-mac is very verbose and of no much use when debugging crashing KDE applications anyways. Also one would not be forced to install qt4-mac +debug from source and only be left with locally rebuilding the much smaller KDE ports. What do you think? Greets, Marko ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
unloading in pre-deactivate
is it feasible to unload a port on pre-deactivate? I noticed that most of the deamons are still loaded and running when you uninstall a port. Rob ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: unloading in pre-deactivate
Hi, is it feasible to unload a port on pre-deactivate? I noticed that most of the deamons are still loaded and running when you uninstall a port. That's certainly a feature we should add to MacPorts base for all ports that install a launchd plist. Ideally, we'd preserve the load state across an upgrade. That would probably mean adding a registry table to store the current load state, unconditionally unload on uninstall and load depending on the information in this table on install/activate. Patches welcome, I guess. If you'd like to work on this and need a couple of pointers to where the relevant code is, don't hesitate to ask. -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: SoQt linking error on Mavericks (10.9.3)
On Jun 28, 2014, at 2:00 PM, Brandon Allbery allber...@gmail.com wrote: Every link-time shared object contains a canonical name telling the dynamic loader how to find the runtime version of the shared object. On OS X with Mach-O, it's called install_name and is a full pathname; there is nothing like ELF's rpath, except that there is now ;-) from man install_name_tool: -rpath old new Changes the rpath path name old to new in the specified Mach-O binary. More than one of these options can be specified. If the Mach-O binary does not contain the old rpath path name in a specified -rpath it is an error. -add_rpath new Adds the rpath path name new in the specified Mach-O binary. More than one of these options can be specified. If the Mach-O binary already contains the new rpath path name specified in -add_rpath it is an error. -delete_rpath old deletes the rpath path name old in the specified Mach-O binary. More than one of these options can be specified. If the Mach-O binary does not contains the old rpath path name specified in -delete_rpath it is an error. we use -add_rpath in the oracle-instantclient port for Leopard and newer... -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Question regarding +debug variant of KDE ports and qt4-mac
I like this as a general idea, because it is often useful to debug some subset of a group of ports, maybe all of the dependent ports, and maybe just the primary port in question. If done correctly, one can enforce variants to get +debug everywhere possible. Or, just for the ports needed. Since +debug is generally not the default, this would help speed up those installs using +debug which would be compiled from source locally. qt4-mac (and, now qt5-mac), are notorious for being enormous time consuming compiles, for which having a pre-compiled binary for most users is a big win. Anyway, I hope I interpreted your proposal correctly, Marko. - MLD On Sun, Jun 29, 2014, at 05:52 AM, Marko Käning wrote: on the kde-mac ML the question came up whether the necessity to install qt4-mac in its debug variant - when one simply needs KDE ports installed in their debug variant - is only due to MacPorts' way of handling port variants... If that's indeed the case, it may seem to be a good idea to replace in all KDE software ports the debug variant by a new variant - perhaps called debug_kde. In that case all ports depending on kdelibs4 would nicely manage their debug_kde variants amongst themselves and not mess with the standard-MacPorts debug variant at all anymore. The debug output of qt4-mac is very verbose and of no much use when debugging crashing KDE applications anyways. Also one would not be forced to install qt4-mac +debug from source and only be left with locally rebuilding the much smaller KDE ports. What do you think? ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Missing (build) dependencies as found through trace mode.
The way I would handle each of those categories would be: - mandatory: simple enough, just use a `port:`-style depspec - recommended: use a `bin:`-style depspec, so the system versions can still satisfy it. Note that the autogen port does not fit in with the rest of the autotools suite, despite its name (this confusion is further compounded by the fact that many software packages call their local autoreconf-equivalent scripts autogen.sh, which is a practice that autotools upstream frowns upon: see http://www.gnu.org/software/automake/manual/html_node/Future-of-aclocal.html#Future-of-aclocal for more on why these scripts are confusing and bad), so I would not include autogen in this category. - optional: make a separate variant for them, depending on what the configure script does with them once it finds them, and use a `port:`-style depspec in the variant. In the apache2 example, only the first one of lynx/links/elinks is actually used, so only a dependency on lynx would be necessary. - very optional: make a separate variant for them, and use a `bin:`-style depspec in the variant. Since the addition of dependencies of this type do not technically change how the software actually gets built (which is what variants are supposed to be used for), be sure to add a note or something mentioning that the variant only exists to placate trace mode's pedantry (and anyone's own personal OCD). Although some people might object to such a variant even with such a note, so you might want to be careful with these ones. - ???: The cctools-headers one reminds me, it would be nice to have a `header:`-style depspec, to match the `bin:`-style and `lib:`-style ones On 6/27/14, Mihai Moldovan io...@ionic.de wrote: This said, I have a rather huge list of ports to upgrade, so I'll keep track of all of them and make a list of categorized missing dependencies. Currently I have the categories: mandatory: build failures recommended: better to have them around, stuff like autogen, automake, autoconf etc. optional: dependencies to make configure happy, like elinks, links, lynx in the apache2 example very optional: being searched for, but system tools can do the job just as well. No build or configure failures due to these, otherwise auto-move to mandatory. Stuff like gawk, gsed, grep, gzip etc. ???: dependencies I have no idea how to handle. Stuff like cctools, cctools-headers, bison etc. Mihai ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Question regarding +debug variant of KDE ports and qt4-mac
On 29/06/2014, at 7:52 PM, Marko Käning wrote: on the kde-mac ML the question came up whether the necessity to install qt4-mac in its debug variant - when one simply needs KDE ports installed in their debug variant - is only due to MacPorts' way of handling port variants... If that's indeed the case, it may seem to be a good idea to replace in all KDE software ports the debug variant by a new variant - perhaps called debug_kde. In that case all ports depending on kdelibs4 would nicely manage their debug_kde variants amongst themselves and not mess with the standard-MacPorts debug variant at all anymore. The debug output of qt4-mac is very verbose and of no much use when debugging crashing KDE applications anyways. Also one would not be forced to install qt4-mac +debug from source and only be left with locally rebuilding the much smaller KDE ports. What do you think? ++1 from me!!! I would also like us to consider something similar for +docs, especially with KDE. That would avoid pulling in all the other text-processing dependencies of other ports, such as the doxygen/texlive/latex chain, while leaving the user to take his or her own chances with meinproc4 (it never fails for me). Also a +docs_kde would not have to be a different binary package - just a downloading and compiling of docs subdirectories with meinproc4, which will be already installed. Come to think of it, I don't think debug or docs in one port is usually dependent on any other port, except for the tools used to format documents, so perhaps MacPorts could have --debug and --docs options for port install, which would apply to the ports that were being requested on that installation run and on upgrades of same. Something like that would give every user fine control over what ports to debug or document, but maybe it is not so easy to implement (?). Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Missing (build) dependencies as found through trace mode.
On 6/29/14, Mihai Moldovan io...@ionic.de wrote:
* On 30.06.2014 04:06 am, Eric Gallager wrote:
Note that the autogen port does not fit in with
the rest of the autotools suite, despite its name
gnutls has been searching for ${prefix}/bin/autogen. Not sure what it meant
to find, exactly. I assumed the autogen port, but this may be wrong.
It doesn't seem to be any part of GNU autotools.
Oh yeah, gnutls is actually the autogen port; I believe we had a
ticket about that: https://trac.macports.org/ticket/42728
- optional: make a separate variant for them, depending on what the
configure script does with them once it finds them, and use a
`port:`-style depspec in the variant. In the apache2 example, only the
first one of lynx/links/elinks is actually used, so only a dependency
on lynx would be necessary.
Also in this case, I tend to put MacPorts-only software in this category.
A lot of those unmet dependencies seem to be stemming from configure trying
find
software to enable additional features. Then again, who would really enable a
gtkdoc variant for gnutls? Wouldn't it be better to just turn this stuff
off via a --disable- or --without- configure switch?
This isn't gtk-doc specifically, but I do have a more general `+docs`
variant in my local gnutls2 Portfile... it also adds a dependency on
`bin:xsltproc:libxslt` and on texinfo, and uses the configure switches
as well:
https://github.com/cooljeanius/LocalPorts/blob/master/devel/gnutls2/Portfile#L182
Even better, cmake's list: (optional) port:bzr port:dpkg port:root5
port:mercurial port:qt4-mac port:openssh port:subversion
file:include/cairo/cairo.h:cairo port:fontconfig port:freetype
port:gdk-pixbuf2
file:include/glib-2.0/glib-object.h:glib port:gtk2
file:include/pango-1.0/pango/pango.h:pango port:gettext port:python26
where are you getting this from?
- very optional: make a separate variant for them, and use a
`bin:`-style depspec in the variant. Since the addition of
dependencies of this type do not technically change how the software
actually gets built (which is what variants are supposed to be used
for), be sure to add a note or something mentioning that the variant
only exists to placate trace mode's pedantry (and anyone's own
personal OCD). Although some people might object to such a variant
even with such a note, so you might want to be careful with these
ones.
Almost every software has a rather long list of this dependency type.
Maybe just ignoring that and letting trace mode bark is good enough here?
As already pointed out by you, there's no functional difference when building
the
software, whether with or without those dependencies.
Creating a variant for everything sounds like a maintaining nightmare
(and it doesn't help us anyway.)
Just to clarify, I didn't mean one variant per dependency, but rather
one mega trace mode compliance variant that has all of them. I
sometimes stick these in a variant where I make other
maintainer-specific changes, such as forcing autoreconfing, or
enabling additional warnings, and stuff like that.
- ???: The cctools-headers one reminds me, it would be nice to have
a `header:`-style depspec, to match the `bin:`-style and `lib:`-style
ones
Yeah, but that's not trivial. See, for instance, gl.h, provided by mesa
and...
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/OpenGL.framework/Versions/A/Headers/
Wouldn't that second one actually be OpenGL/gl.h as opposed to the
GL/gl.h that mesa installs, due to how framework headers are
written?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
python dependancy
How does one indicate a python lib dependance in a port file that requires it? Add the portgroup python? Mark ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
