Re: python dependancy
On 2014-6-30 15:48 , Mark Brethen wrote: > How does one indicate a python lib dependance in a port file that requires > it? Add the portgroup python? The python portgroup is only for stuff that installs with a setup.py. If that's not the case here, just add a python dep like you would any other port. - Josh ___ 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
Re: Missing (build) dependencies as found through trace mode.
On 6/29/14, Mihai Moldovan 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 as opposed to the
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
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 30.06.2014 04:06 am, Eric Gallager wrote:
> The way I would handle each of those categories would be:
>
> - "mandatory": simple enough, just use a `port:`-style depspec
Yes, mandatory will be fixed right away. I already hit a few of those and am
fixing them as go.
> - "recommended": use a `bin:`-style depspec, so the system versions
> can still satisfy it.
I will also try to gradually add "recommended" dependencies to port files, but
with lower priority, as those are not fatal. Not with a bin-style depspec,
though, as my "recommended" category basically only consists of MacPorts-only
software (so far.)
> 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.
> - "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?
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
In such cases, I'd rather have "automatic dependencies" whenever some port is
installed enabling features or not. This basically happens when not building in
trace mode. However, it makes building non-deterministic...
> - "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.)
> - "???": 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/
Hohum.
Concerning cctools, we might be interested in using as, ar, ranlib et. al.
provided by the system, not MacPorts, as we already defaulting to the system
compiler. As such, I'd also ignore cctools whenever they come up (unless they
are promoted to "mandatory", as is the case for gcc4*. I'll file a bug report
about those build failures "later today".
Thank you for your input!
Mihai
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: 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 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
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: SoQt linking error on Mavericks (10.9.3)
On Jun 28, 2014, at 2:00 PM, Brandon Allbery 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: 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
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
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
