Re: Questions on dependencies
On Tue, Nov 12, 2013 at 10:52:20PM +0100, Peter Danecek wrote: > I tried to run in trace mode, however, I have not installed base from > trunk, so I am not sure if it is already reporting correctly. If it doesn't outright crash or fail to build, it might be better than nothing, but trace mode in 2.2.1 has a number of issues like race conditions, not being thread-safe (i.e. it breaks when used from multithreaded programs) and not catching all necessary system calls. I wouldn't rely on it. -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Questions on dependencies
Hi all, I tried to respect the recommendations here and this is what I came up with: http://trac.macports.org/ticket/41337 I tried to run in trace mode, however, I have not installed base from trunk, so I am not sure if it is already reporting correctly. It would report to a missing libgcc dependency. But the only relation I see here, would be py-scipy, which I consider a runtime dependency only. Any comments? ~petr On Nov 11, 2013, at 6:11 , Joshua Root wrote: > On 2013-11-10 23:23 , Michael Dickens wrote: >> On Sun, Nov 10, 2013, at 12:47 AM, Joshua Root wrote: >>> On 2013-11-10 05:35 , Craig Treleaven wrote: Perhaps just the documentation for depends_lib should be expanded to say that it indicates both compiled and interpreted linkages? >>> >>> It doesn't indicate anything about linkage, it indicates that the >>> dependency is needed at both build time and run time. >> >> How does one indicate a runtime dependency that is checked for at >> configure time and not used for building or linking? I've been using >> depends_run, but I'm not sure that always works because of the >> configuration checking. Are these dependencies installed before >> configuration of the target port? Do we need to redefine (as per this >> thread) what the depends_* actually mean, to make checking for linkage >> versus usage, and when the usage is checked for and used (to my count: 3 >> different depends_*, I think as we have now)? - MLD > > If it needs to be there at configure time then it's depends_build or > depends_lib. Since it's also needed at runtime, it's the latter. > > - Josh > ___ > 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: Questions on dependencies
On 2013-11-10 23:23 , Michael Dickens wrote: > On Sun, Nov 10, 2013, at 12:47 AM, Joshua Root wrote: >> On 2013-11-10 05:35 , Craig Treleaven wrote: >>> Perhaps just the >>> documentation for depends_lib should be expanded to say that it >>> indicates both compiled and interpreted linkages? >> >> It doesn't indicate anything about linkage, it indicates that the >> dependency is needed at both build time and run time. > > How does one indicate a runtime dependency that is checked for at > configure time and not used for building or linking? I've been using > depends_run, but I'm not sure that always works because of the > configuration checking. Are these dependencies installed before > configuration of the target port? Do we need to redefine (as per this > thread) what the depends_* actually mean, to make checking for linkage > versus usage, and when the usage is checked for and used (to my count: 3 > different depends_*, I think as we have now)? - MLD If it needs to be there at configure time then it's depends_build or depends_lib. Since it's also needed at runtime, it's the latter. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Questions on dependencies
On Nov 10, 2013, at 7:23 AM, Michael Dickens wrote: > How does one indicate a runtime dependency that is checked for at > configure time and not used for building or linking? As previously stated, one could use either depends_lib or depends_build + depends_run, because depends_lib does not currently mean anything other than "required at both build time and run time". > I've been using depends_run, but I'm not sure that always works because of the > configuration checking. Are these dependencies installed before configuration > of the target port? This is incorrect because there is no guarantee that the dependency will be present during the configure phase. Running "port configure foo" will not trigger installation of foo's runtime dependencies. It's easy to miss this if you always have the dependencies installed, or if you test with "port install foo", which (I believe) installs all dependencies before starting on foo. vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Questions on dependencies
Depends_build and depends_lib are installed prior to build phase, and depends_run prior to activate. Depends_extract for extract phase, etc. So a dependency marked as depends_run will not be installed prior to configuration. On Sun, 10 Nov 2013 07:23:47 -0500, Michael Dickens wrote: On Sun, Nov 10, 2013, at 12:47 AM, Joshua Root wrote: On 2013-11-10 05:35 , Craig Treleaven wrote: > Perhaps just the > documentation for depends_lib should be expanded to say that it > indicates both compiled and interpreted linkages? It doesn't indicate anything about linkage, it indicates that the dependency is needed at both build time and run time. How does one indicate a runtime dependency that is checked for at configure time and not used for building or linking? I've been using depends_run, but I'm not sure that always works because of the configuration checking. Are these dependencies installed before configuration of the target port? Do we need to redefine (as per this thread) what the depends_* actually mean, to make checking for linkage versus usage, and when the usage is checked for and used (to my count: 3 different depends_*, I think as we have now)? - MLD ___ 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: Questions on dependencies
On Sun, Nov 10, 2013, at 12:47 AM, Joshua Root wrote: > On 2013-11-10 05:35 , Craig Treleaven wrote: > > Perhaps just the > > documentation for depends_lib should be expanded to say that it > > indicates both compiled and interpreted linkages? > > It doesn't indicate anything about linkage, it indicates that the > dependency is needed at both build time and run time. How does one indicate a runtime dependency that is checked for at configure time and not used for building or linking? I've been using depends_run, but I'm not sure that always works because of the configuration checking. Are these dependencies installed before configuration of the target port? Do we need to redefine (as per this thread) what the depends_* actually mean, to make checking for linkage versus usage, and when the usage is checked for and used (to my count: 3 different depends_*, I think as we have now)? - MLD ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Questions on dependencies
On 2013-11-10 05:35 , Craig Treleaven wrote: > Perhaps just the > documentation for depends_lib should be expanded to say that it > indicates both compiled and interpreted linkages? It doesn't indicate anything about linkage, it indicates that the dependency is needed at both build time and run time. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Questions on dependencies
On Nov 9, 2013, at 12:35, Craig Treleaven wrote: > My port uses p5.12-libwww-perl which relies on a list of other perl modules. You should actually declare dependencies on the specific other modules that you use, not libwww-perl itself anymore. $ port notes p5-libwww-perl p5-libwww-perl has the following notes: As of version 6.00, libwww-perl has been broken up into multiple packages. If you were using p5-libwww-perl for just one or two of its modules before, you may be able to pare down your installation to just those modules now. Other important changes have been made that may affect your code; for details, please see: /opt/local/share/doc/p5-libwww-perl/Changes ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Questions on dependencies
Speaking of my script, I've made a bunch of changes to it recently, so I'll
probably need to create a new tag sometime so I can update the
`macportsscripts` port that points to it... The version from 0.1.4 still
reports library links that are there due to libtool overlinking, and I've
been working on finding ways to ignore those links, mainly by checking for
symbol usage with `nm`...
On Fri, Nov 8, 2013 at 10:34 PM, Craig Treleaven wrote:
> At 4:27 PM +0100 11/1/13, Clemens Lang wrote:
>
>> On Fri, Nov 01, 2013 at 10:27:04AM +1100, Joshua Root wrote:
>>
>>> If they are needed at build time and runtime, use depends_lib. If they
>>> are only needed at runtime, use depends_run.
>>>
>>
>> is there any difference between listing a package in both depends_build
>> and depends_run compared to just listing it in depends_lib, e.g. in how
>> licensing stuff propagates?
>>
>> Since MacPorts ensures depends_run dependencies are installed before
>> attempting to build a package, we usually do not notice a depends_run
>> dependency that should rather be depends_build.
>>
>> I'm currently trying to improve trace mode to a point where every
>> package I have installed builds fine using trace mode and I've come
>> across the gcc ports, which set
>> depends_run port:ld64 port:cctools
>> but fail to configure when trace mode (correctly) hides files installed
>> by these ports. I wonder whether the correct fix would be to convert
>> those into depends_lib, or just add them as depends_build, too.
>>
>
> I was playing with egall's port-depcheck.sh script:
>
> https://github.com/cooljeanius/macportsscripts/
> blob/v0.1.4/port-depcheck.sh
>
> It identified several interesting things in my MythTV ports that I hadn't
> known before--including a couple more opportunistic links (Myth is so
> promiscuous!).
>
> A couple of questions for the more-experienced here.
>
> Myth includes Perl and Python bindings that need a number of dependencies
> to work (eg port:${pymodver}-mysql, port:${perlmodver}-dbd-mysql, etc). I
> have these listed as depends_lib but no Myth binaries link directly to
> them. Is it advantageous to list them instead as depends_run?
>
> egall's script says that Myth does not link directly to
> qt4-mac-${mysqlver}-plugin but does link directly to qt4-mac. Again, are
> there advantages to showing qt4-mac as a depends_lib but the plugin as a
> depends_run?
>
> I'm not a professional developer; just trying to understand a little more.
>
> Thanks,
>
> Craig
>
> ___
> 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: Questions on dependencies
On Nov 9, 2013, at 1:35 PM, Craig Treleaven wrote: > So, in a way, we all use depends_lib for certain things as a short-hand for > listing stuff as both depends_build and depends_run, no? That's the general usage, yes. > In a perfect world, maybe we should have a "depends_mod" for indicating a > dependency on an interpreted module (perl, python, php, ruby, ...)? It would > express the relationship more precisely, I think. OTOH, I don't see any > particular advantage other than that and it would be a tremendous amount of > work to got through all existing ports and split depends_mod out from > depends_lib as necessary. Perhaps just the documentation for depends_lib > should be expanded to say that it indicates both compiled and interpreted > linkages? That's what this whole conversation has been about: whether "depends_lib" can just be shorthand for "depends_build" + "depends_run", or whether it should specifically indicate linkage. vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Questions on dependencies
At 11:48 AM -0500 11/9/13, Jeremy Lavergne wrote:
Myth includes Perl and Python bindings that need a number of
dependencies to work (eg port:${pymodver}-mysql,
port:${perlmodver}-dbd-mysql, etc). I have these listed as
depends_lib but no Myth binaries link directly to them. Is it
advantageous to list them instead as depends_run?
The packages aren't guaranteed to be available during build time if
it's only a depends_run. You might need them listed in both
depends_build and depends_run, if the bindings aren't always built.
egall's script says that Myth does not link directly to
qt4-mac-${mysqlver}-plugin but does link directly to qt4-mac.
Again, are there advantages to showing qt4-mac as a depends_lib but
the plugin as a depends_run?
Again, qt4-mac should definitely be listed as depends_lib, but the
plugin might need both _run and _build.
Try setting the plugin dependency to _run and deactivate it, then
build and see if your package still uses it. If so, then the plugin
isn't needed during _build. If it doesn't work then you need it in
both _build and _run.
So, in a way, we all use depends_lib for certain things as a
short-hand for listing stuff as both depends_build and depends_run,
no? For example, I was looking at some of the perl modules. My port
uses p5.12-libwww-perl which relies on a list of other perl modules.
Using port-depcheck confirms that no compiled library links. Of the
rdeps for p5.12-libwww-perl, only a couple of lower level modules
appear to link directly to a compiled library, eg p5.12-net-ssleay.
In a perfect world, maybe we should have a "depends_mod" for
indicating a dependency on an interpreted module (perl, python, php,
ruby, ...)? It would express the relationship more precisely, I
think. OTOH, I don't see any particular advantage other than that
and it would be a tremendous amount of work to got through all
existing ports and split depends_mod out from depends_lib as
necessary. Perhaps just the documentation for depends_lib should be
expanded to say that it indicates both compiled and interpreted
linkages?
Craig
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Questions on dependencies
Myth includes Perl and Python bindings that need a number of
dependencies to work (eg port:${pymodver}-mysql,
port:${perlmodver}-dbd-mysql, etc). I have these listed as depends_lib
but no Myth binaries link directly to them. Is it advantageous to list
them instead as depends_run?
The packages aren't guaranteed to be available during build time if it's
only a depends_run. You might need them listed in both depends_build and
depends_run, if the bindings aren't always built.
egall's script says that Myth does not link directly to
qt4-mac-${mysqlver}-plugin but does link directly to qt4-mac. Again,
are there advantages to showing qt4-mac as a depends_lib but the plugin
as a depends_run?
Again, qt4-mac should definitely be listed as depends_lib, but the plugin
might need both _run and _build.
Try setting the plugin dependency to _run and deactivate it, then build
and see if your package still uses it. If so, then the plugin isn't needed
during _build. If it doesn't work then you need it in both _build and _run.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Questions on dependencies
At 4:27 PM +0100 11/1/13, Clemens Lang wrote:
On Fri, Nov 01, 2013 at 10:27:04AM +1100, Joshua Root wrote:
If they are needed at build time and runtime, use depends_lib. If they
are only needed at runtime, use depends_run.
is there any difference between listing a package in both depends_build
and depends_run compared to just listing it in depends_lib, e.g. in how
licensing stuff propagates?
Since MacPorts ensures depends_run dependencies are installed before
attempting to build a package, we usually do not notice a depends_run
dependency that should rather be depends_build.
I'm currently trying to improve trace mode to a point where every
package I have installed builds fine using trace mode and I've come
across the gcc ports, which set
depends_run port:ld64 port:cctools
but fail to configure when trace mode (correctly) hides files installed
by these ports. I wonder whether the correct fix would be to convert
those into depends_lib, or just add them as depends_build, too.
I was playing with egall's port-depcheck.sh script:
https://github.com/cooljeanius/macportsscripts/blob/v0.1.4/port-depcheck.sh
It identified several interesting things in my MythTV ports that I
hadn't known before--including a couple more opportunistic links
(Myth is so promiscuous!).
A couple of questions for the more-experienced here.
Myth includes Perl and Python bindings that need a number of
dependencies to work (eg port:${pymodver}-mysql,
port:${perlmodver}-dbd-mysql, etc). I have these listed as
depends_lib but no Myth binaries link directly to them. Is it
advantageous to list them instead as depends_run?
egall's script says that Myth does not link directly to
qt4-mac-${mysqlver}-plugin but does link directly to qt4-mac. Again,
are there advantages to showing qt4-mac as a depends_lib but the
plugin as a depends_run?
I'm not a professional developer; just trying to understand a little more.
Thanks,
Craig
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Questions on dependencies
On 2013-11-2 10:12 , Ryan Schmidt wrote: > On Nov 1, 2013, at 17:25, Joshua Root wrote: > >> On 2013-11-2 02:27 , Clemens Lang wrote: >> >>> I'm currently trying to improve trace mode to a point where every >>> package I have installed builds fine using trace mode and I've come >>> across the gcc ports, which set >>> depends_run port:ld64 port:cctools >>> but fail to configure when trace mode (correctly) hides files installed >>> by these ports. I wonder whether the correct fix would be to convert >>> those into depends_lib, or just add them as depends_build, too. >> >> The former. > > If that’s general advice, then how do you suggest we differentiate between > ports depending on ImageMagick for its libraries vs. those depending on it > for its programs? The best way would probably be to use libmachista during the install phase to determine what the mach-o files in each port are linked with, and record that in the archive metadata and the registry. Then, much like the problem of finding out which (uninstalled) port provides a file you want, it's just a matter of setting up a way to query that information. Or if you want a way that doesn't involve writing any code, figure out the linking situation manually and put a comment in the portfile. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Questions on dependencies
On Nov 1, 2013, at 17:25, Joshua Root wrote: > On 2013-11-2 02:27 , Clemens Lang wrote: > >> I'm currently trying to improve trace mode to a point where every >> package I have installed builds fine using trace mode and I've come >> across the gcc ports, which set >> depends_run port:ld64 port:cctools >> but fail to configure when trace mode (correctly) hides files installed >> by these ports. I wonder whether the correct fix would be to convert >> those into depends_lib, or just add them as depends_build, too. > > The former. If that’s general advice, then how do you suggest we differentiate between ports depending on ImageMagick for its libraries vs. those depending on it for its programs? Perhaps this isn’t the general-purpose problem I think it is. For example, when we had this problem with the “file” port and its “libmagic” library, I solved it by breaking libmagic out into its own subport. Maybe I should break the ImageMagick libraries out into their own subport too. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Questions on dependencies
On 2013-11-2 02:27 , Clemens Lang wrote: > Hi, > > On Fri, Nov 01, 2013 at 10:27:04AM +1100, Joshua Root wrote: >> If they are needed at build time and runtime, use depends_lib. If they >> are only needed at runtime, use depends_run. > > is there any difference between listing a package in both depends_build > and depends_run compared to just listing it in depends_lib, e.g. in how > licensing stuff propagates? The only difference is that the dependency is processed twice. > Since MacPorts ensures depends_run dependencies are installed before > attempting to build a package, we usually do not notice a depends_run > dependency that should rather be depends_build. Yep. This isn't an entirely academic problem either, since it can cause failures when running e.g. 'port configure'. > I'm currently trying to improve trace mode to a point where every > package I have installed builds fine using trace mode and I've come > across the gcc ports, which set > depends_run port:ld64 port:cctools > but fail to configure when trace mode (correctly) hides files installed > by these ports. I wonder whether the correct fix would be to convert > those into depends_lib, or just add them as depends_build, too. The former. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Questions on dependencies
On Nov 1, 2013, at 4:15 PM, Ryan Schmidt wrote: > On Nov 1, 2013, at 15:09, Daniel J. Luke wrote: >> which again, you're assuming that no port has a runtime dependency on a >> library that doesn't link with that library (which a reasonable person might >> express as a depends_run dependency). This is #2 from above. >> >> The only way you can assume that depends_run means "only depends on >> programs" is if we define depends_run to mean "only depends on programs”. > > I *do not* "assume that depends_run means 'only depends on programs’”. My > proposal is that depends_lib means a port links with a library. Therefore, > using depends_run instead means a port does not link with a library. ok, then you're assuming that ports that load a library/plugin at runtime won't need a revbump if the library ABI changes (but something that links with that library does need a revbump). I don't know if that's a reasonable assumption or not (it probably /should/ be, but I don't know if things work that well in practice or not). -- 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: Questions on dependencies
On Nov 1, 2013, at 15:09, Daniel J. Luke wrote: > which again, you're assuming that no port has a runtime dependency on a > library that doesn't link with that library (which a reasonable person might > express as a depends_run dependency). This is #2 from above. > > The only way you can assume that depends_run means "only depends on programs" > is if we define depends_run to mean "only depends on programs”. I *do not* "assume that depends_run means 'only depends on programs’”. My proposal is that depends_lib means a port links with a library. Therefore, using depends_run instead means a port does not link with a library. > In other words, for this to work, depends_lib doesn't just mean "I link to a > library provided by this port" but "I link to, or load a library or plugin > provided by this port." No, my proposal is that depends_lib means it links with a library. If a port loads a library at runtime, that would be depends_run. Perhaps that’s unintuitive. I guess I’m redefining depends_lib to be more “depends_link”. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Questions on dependencies
On Nov 1, 2013, at 4:04 PM, Ryan Schmidt wrote: > On Nov 1, 2013, at 15:02, Daniel J. Luke wrote: >> On Nov 1, 2013, at 3:58 PM, Ryan Schmidt wrote: >>> On Nov 1, 2013, at 14:55, Daniel J. Luke wrote: On Nov 1, 2013, at 3:50 PM, Ryan Schmidt wrote: > On Nov 1, 2013, at 14:44, Daniel J. Luke wrote: >> On Nov 1, 2013, at 2:09 PM, Ryan Schmidt wrote: >>> The solution would be for ports that use the ImageMagick libraries to >>> depend on it via depends_lib and for those only needing its programs to >>> depend on it via depends_build and/or depends_run. >> >> I don't think you can say depends_run means 'only depends on programs' >> unless we specifically define it to mean that (I can think of a case >> where something doesn't link with a library or plugin, but loads it at >> runtime). > > I didn’t say that. I said perhaps we should make “depends_lib” mean that > it depends on (i.e. links with) a library. That doesn’t seem so > unreasonable. the quoted sentence indicates: 1. depends_lib == linked to it (needs revbump) 2. depends_build/depends_run == only needs its programs. I'm saying that unless we define depends_build/depends_run as only pertaining to programs, that 2 isn't necessarily true (an application can have a runtime dependency on a library or plugin that it loads at runtime but isn't linked with). >>> >>> Sorry if I was unclear. My only proposal is: >>> >>> depends_lib should mean that a port links with another port’s library, such >>> that it needs a revbump if that port’s library version increases >>> >>> If you link with another port’s library, use depends_lib >>> >>> If you do not link with another port’s library, do not use depends_lib >> >> ok, so you don't actually want to fix the problem you have with some things >> depending on ImageMagic libraries and some things depending on just the >> programs? :) > > The way I want to fix it is to go through the ports that depend on > ImageMagick, find those that declare “depends_lib port:ImageMagick” but only > use its programs, and change them to “depends_run port:ImageMagick” > (presuming they use the programs at runtime) and if they check for the > presence of the program at configure time, then also add “depends_build > port:ImageMagick”. which again, you're assuming that no port has a runtime dependency on a library that doesn't link with that library (which a reasonable person might express as a depends_run dependency). This is #2 from above. The only way you can assume that depends_run means "only depends on programs" is if we define depends_run to mean "only depends on programs". In other words, for this to work, depends_lib doesn't just mean "I link to a library provided by this port" but "I link to, or load a library or plugin provided by this port." I don't think it's a /bad/ idea to define things that way, just that it needs to be clear so that maintainers use depends_lib/depends_run in a way that is consistent. > The part of the question I was replying to was "is there any difference > between listing a package in both depends_build and depends_run compared to > just listing it in depends_lib”. I was trying to explain what I thought the > difference should be. -- 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: Questions on dependencies
On Nov 1, 2013, at 15:02, Daniel J. Luke wrote: > On Nov 1, 2013, at 3:58 PM, Ryan Schmidt wrote: >> On Nov 1, 2013, at 14:55, Daniel J. Luke wrote: >>> On Nov 1, 2013, at 3:50 PM, Ryan Schmidt wrote: On Nov 1, 2013, at 14:44, Daniel J. Luke wrote: > On Nov 1, 2013, at 2:09 PM, Ryan Schmidt wrote: >> The solution would be for ports that use the ImageMagick libraries to >> depend on it via depends_lib and for those only needing its programs to >> depend on it via depends_build and/or depends_run. > > I don't think you can say depends_run means 'only depends on programs' > unless we specifically define it to mean that (I can think of a case > where something doesn't link with a library or plugin, but loads it at > runtime). I didn’t say that. I said perhaps we should make “depends_lib” mean that it depends on (i.e. links with) a library. That doesn’t seem so unreasonable. >>> >>> the quoted sentence indicates: >>> >>> 1. depends_lib == linked to it (needs revbump) >>> 2. depends_build/depends_run == only needs its programs. >>> >>> I'm saying that unless we define depends_build/depends_run as only >>> pertaining to programs, that 2 isn't necessarily true (an application can >>> have a runtime dependency on a library or plugin that it loads at runtime >>> but isn't linked with). >> >> Sorry if I was unclear. My only proposal is: >> >> depends_lib should mean that a port links with another port’s library, such >> that it needs a revbump if that port’s library version increases >> >> If you link with another port’s library, use depends_lib >> >> If you do not link with another port’s library, do not use depends_lib > > ok, so you don't actually want to fix the problem you have with some things > depending on ImageMagic libraries and some things depending on just the > programs? :) The way I want to fix it is to go through the ports that depend on ImageMagick, find those that declare “depends_lib port:ImageMagick” but only use its programs, and change them to “depends_run port:ImageMagick” (presuming they use the programs at runtime) and if they check for the presence of the program at configure time, then also add “depends_build port:ImageMagick”. The part of the question I was replying to was "is there any difference between listing a package in both depends_build and depends_run compared to just listing it in depends_lib”. I was trying to explain what I thought the difference should be. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Questions on dependencies
On Nov 1, 2013, at 3:58 PM, Ryan Schmidt wrote: > On Nov 1, 2013, at 14:55, Daniel J. Luke wrote: >> On Nov 1, 2013, at 3:50 PM, Ryan Schmidt wrote: >>> On Nov 1, 2013, at 14:44, Daniel J. Luke wrote: On Nov 1, 2013, at 2:09 PM, Ryan Schmidt wrote: > The solution would be for ports that use the ImageMagick libraries to > depend on it via depends_lib and for those only needing its programs to > depend on it via depends_build and/or depends_run. I don't think you can say depends_run means 'only depends on programs' unless we specifically define it to mean that (I can think of a case where something doesn't link with a library or plugin, but loads it at runtime). >>> >>> I didn’t say that. I said perhaps we should make “depends_lib” mean that it >>> depends on (i.e. links with) a library. That doesn’t seem so unreasonable. >> >> the quoted sentence indicates: >> >> 1. depends_lib == linked to it (needs revbump) >> 2. depends_build/depends_run == only needs its programs. >> >> I'm saying that unless we define depends_build/depends_run as only >> pertaining to programs, that 2 isn't necessarily true (an application can >> have a runtime dependency on a library or plugin that it loads at runtime >> but isn't linked with). > > Sorry if I was unclear. My only proposal is: > > depends_lib should mean that a port links with another port’s library, such > that it needs a revbump if that port’s library version increases > > If you link with another port’s library, use depends_lib > > If you do not link with another port’s library, do not use depends_lib ok, so you don't actually want to fix the problem you have with some things depending on ImageMagic libraries and some things depending on just the programs? :) -- 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: Questions on dependencies
On Nov 1, 2013, at 14:55, Daniel J. Luke wrote: > On Nov 1, 2013, at 3:50 PM, Ryan Schmidt wrote: >> On Nov 1, 2013, at 14:44, Daniel J. Luke wrote: >>> On Nov 1, 2013, at 2:09 PM, Ryan Schmidt wrote: The solution would be for ports that use the ImageMagick libraries to depend on it via depends_lib and for those only needing its programs to depend on it via depends_build and/or depends_run. >>> >>> I don't think you can say depends_run means 'only depends on programs' >>> unless we specifically define it to mean that (I can think of a case where >>> something doesn't link with a library or plugin, but loads it at runtime). >> >> I didn’t say that. I said perhaps we should make “depends_lib” mean that it >> depends on (i.e. links with) a library. That doesn’t seem so unreasonable. > > the quoted sentence indicates: > > 1. depends_lib == linked to it (needs revbump) > 2. depends_build/depends_run == only needs its programs. > > I'm saying that unless we define depends_build/depends_run as only pertaining > to programs, that 2 isn't necessarily true (an application can have a runtime > dependency on a library or plugin that it loads at runtime but isn't linked > with). Sorry if I was unclear. My only proposal is: depends_lib should mean that a port links with another port’s library, such that it needs a revbump if that port’s library version increases If you link with another port’s library, use depends_lib If you do not link with another port’s library, do not use depends_lib ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Questions on dependencies
On Nov 1, 2013, at 3:50 PM, Ryan Schmidt wrote: > On Nov 1, 2013, at 14:44, Daniel J. Luke wrote: >> On Nov 1, 2013, at 2:09 PM, Ryan Schmidt wrote: >>> The solution would be for ports that use the ImageMagick libraries to >>> depend on it via depends_lib and for those only needing its programs to >>> depend on it via depends_build and/or depends_run. >> >> I don't think you can say depends_run means 'only depends on programs' >> unless we specifically define it to mean that (I can think of a case where >> something doesn't link with a library or plugin, but loads it at runtime). > > I didn’t say that. I said perhaps we should make “depends_lib” mean that it > depends on (i.e. links with) a library. That doesn’t seem so unreasonable. the quoted sentence indicates: 1. depends_lib == linked to it (needs revbump) 2. depends_build/depends_run == only needs its programs. I'm saying that unless we define depends_build/depends_run as only pertaining to programs, that 2 isn't necessarily true (an application can have a runtime dependency on a library or plugin that it loads at runtime but isn't linked with). -- 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: Questions on dependencies
On Nov 1, 2013, at 14:44, Daniel J. Luke wrote: > On Nov 1, 2013, at 2:09 PM, Ryan Schmidt wrote: >> I’m not sure if there’s any licensing difference. Historically, we’ve said >> that if a dependency is needed at build time and at runtime, then it should >> be listed in only depends_lib, even if it is not a library. However I think >> we should change our thinking this and use depends_lib only to indicate >> library dependencies. The reason is that some ports provide both libraries >> and programs. I’m thinking specifically of ImageMagick, which might be >> depended upon either for its libraries like libMagickCore or for its >> programs like convert. When libMagickCore’s library version number >> increases, I need to be able to identify which ports are linking with >> ImageMagick’s libraries, so that I can revbump them so that they rebuild, >> but I don’t want to unnecessarily revbump those ports only using >> ImageMagick’s programs. The solution would be for ports that use the >> ImageMagick libraries to depend on it via depends_lib and for those only >> needing its programs to depend on it via depends_build and/or depends_run. > > I don't think you can say depends_run means 'only depends on programs' unless > we specifically define it to mean that (I can think of a case where something > doesn't link with a library or plugin, but loads it at runtime). I didn’t say that. I said perhaps we should make “depends_lib” mean that it depends on (i.e. links with) a library. That doesn’t seem so unreasonable. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Questions on dependencies
On Nov 1, 2013, at 2:09 PM, Ryan Schmidt wrote: > I’m not sure if there’s any licensing difference. Historically, we’ve said > that if a dependency is needed at build time and at runtime, then it should > be listed in only depends_lib, even if it is not a library. However I think > we should change our thinking this and use depends_lib only to indicate > library dependencies. The reason is that some ports provide both libraries > and programs. I’m thinking specifically of ImageMagick, which might be > depended upon either for its libraries like libMagickCore or for its programs > like convert. When libMagickCore’s library version number increases, I need > to be able to identify which ports are linking with ImageMagick’s libraries, > so that I can revbump them so that they rebuild, but I don’t want to > unnecessarily revbump those ports only using ImageMagick’s programs. The > solution would be for ports that use the ImageMagick libraries to depend on > it via depends_lib and for those only needing its programs to depend on it > via depends_build and/or depends_run. I don't think you can say depends_run means 'only depends on programs' unless we specifically define it to mean that (I can think of a case where something doesn't link with a library or plugin, but loads it at runtime). -- 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: Questions on dependencies
We use “installs_libs no” to indicate that a port that other ports depend on does not install any libraries. That’s no help when the port does install libraries, like ImageMagick does. On Nov 1, 2013, at 13:11, Jeremy Lavergne wrote: > I think we use `installs_libs no` for those licensing checks. > > On Nov 1, 2013, at 14:09, Ryan Schmidt wrote: > >> I’m not sure if there’s any licensing difference. Historically, we’ve said >> that if a dependency is needed at build time and at runtime, then it should >> be listed in only depends_lib, even if it is not a library. However I think >> we should change our thinking this and use depends_lib only to indicate >> library dependencies. The reason is that some ports provide both libraries >> and programs. I’m thinking specifically of ImageMagick, which might be >> depended upon either for its libraries like libMagickCore or for its >> programs like convert. When libMagickCore’s library version number >> increases, I need to be able to identify which ports are linking with >> ImageMagick’s libraries, so that I can revbump them so that they rebuild, >> but I don’t want to unnecessarily revbump those ports only using >> ImageMagick’s programs. The solution would be for ports that use the >> ImageMagick libraries to depend on it via depends_lib and for those only >> needing its programs to depend on it via depends_build and/or depends_run. > ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Questions on dependencies
I think we use `installs_libs no` for those licensing checks. On Nov 1, 2013, at 14:09, Ryan Schmidt wrote: > I’m not sure if there’s any licensing difference. Historically, we’ve said > that if a dependency is needed at build time and at runtime, then it should > be listed in only depends_lib, even if it is not a library. However I think > we should change our thinking this and use depends_lib only to indicate > library dependencies. The reason is that some ports provide both libraries > and programs. I’m thinking specifically of ImageMagick, which might be > depended upon either for its libraries like libMagickCore or for its programs > like convert. When libMagickCore’s library version number increases, I need > to be able to identify which ports are linking with ImageMagick’s libraries, > so that I can revbump them so that they rebuild, but I don’t want to > unnecessarily revbump those ports only using ImageMagick’s programs. The > solution would be for ports that use the ImageMagick libraries to depend on > it via depends_lib and for those only needing its programs to depend on it > via depends_build and/or depends_run. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Questions on dependencies
On Nov 1, 2013, at 10:27, Clemens Lang wrote: > is there any difference between listing a package in both depends_build > and depends_run compared to just listing it in depends_lib, e.g. in how > licensing stuff propagates? I’m not sure if there’s any licensing difference. Historically, we’ve said that if a dependency is needed at build time and at runtime, then it should be listed in only depends_lib, even if it is not a library. However I think we should change our thinking this and use depends_lib only to indicate library dependencies. The reason is that some ports provide both libraries and programs. I’m thinking specifically of ImageMagick, which might be depended upon either for its libraries like libMagickCore or for its programs like convert. When libMagickCore’s library version number increases, I need to be able to identify which ports are linking with ImageMagick’s libraries, so that I can revbump them so that they rebuild, but I don’t want to unnecessarily revbump those ports only using ImageMagick’s programs. The solution would be for ports that use the ImageMagick libraries to depend on it via depends_lib and for those only needing its programs to depend on it via depends_build and/or depends_run. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Questions on dependencies
On Fri, Nov 01, 2013 at 04:27:40PM +0100, Clemens Lang wrote: > I'm currently trying to improve trace mode to a point where every > package I have installed builds fine using trace mode and I've come > across the gcc ports, which set > depends_run port:ld64 port:cctools > but fail to configure when trace mode (correctly) hides files installed > by these ports. I wonder whether the correct fix would be to convert > those into depends_lib, or just add them as depends_build, too. The same thing applies to xorg-xcb-proto declaring depends_run on python packages but checking for the python binaries in configure. To: Jeremy Huddleston, who maintains xorg-xcb-proto -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Questions on dependencies
Hi, On Fri, Nov 01, 2013 at 10:27:04AM +1100, Joshua Root wrote: > If they are needed at build time and runtime, use depends_lib. If they > are only needed at runtime, use depends_run. is there any difference between listing a package in both depends_build and depends_run compared to just listing it in depends_lib, e.g. in how licensing stuff propagates? Since MacPorts ensures depends_run dependencies are installed before attempting to build a package, we usually do not notice a depends_run dependency that should rather be depends_build. I'm currently trying to improve trace mode to a point where every package I have installed builds fine using trace mode and I've come across the gcc ports, which set depends_run port:ld64 port:cctools but fail to configure when trace mode (correctly) hides files installed by these ports. I wonder whether the correct fix would be to convert those into depends_lib, or just add them as depends_build, too. -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Questions on dependencies
On 2013-11-1 05:54 , Peter Danecek wrote: > > Hi all, > > I'm somewhat puzzled with the dependencies of some ports, and I realise the I > lack some basic understanding. > > (1) py-cython > > From what I understand, build dependencies are required during the build, but > can be removed later. Also they are not required for installation of prebuilt > packages. But I have no clear idea if `py-cython` is a build dependency or a > lib dependency. Looking through the existing ports, I find both. > > Is `py??-cython` required after the build? A lot of software will use cython at build time only, but it's possible that some uses it at runtime. You would have to check how it is used in your specific case. > (2) python package dependencies > > Intuitively, I would say that most python package dependencies were lib > dependencies. But they actually may install without, right? So is it okay to > declare them lib dependencies or might it be better to make them runtime > dependencies? If they are needed at build time and runtime, use depends_lib. If they are only needed at runtime, use depends_run. > (3) What exactly makes a lib a dependency in Macports? See above. > I have the situation that some software depend on some library, its headers > are included it is linked against it. Okay, here the situation is clear. But > this lib may again depend on other libs, but my software does not directly > reference/call these libraries. (It may need to link against it, not > completely clear to me). Is this library a dependency for Macports or would I > rely on the fact, that the library I am referencing directly, would have > these other libraries as dependencies? It's safest to have a port explicitly depend on everything that the software installed by that port uses directly. That way, if the dependencies change their dependencies at some point, you don't have the possibility of something you need disappearing from your nominal dependency tree. For example, if the software calls libpng functions, you of course must depend on libpng. Libpng internally calls zlib functions, but you don't need to list a dependency on zlib unless the port also calls zlib functions directly. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Questions on dependencies
On Oct 31, 2013, at 2:54 PM, Peter Danecek wrote: > (2) python package dependencies > > Intuitively, I would say that most python package dependencies were lib > dependencies. But they actually may install without, right? So is it okay to > declare them lib dependencies or might it be better to make them runtime > dependencies? If the presence of a dependency does not affect the installation, it should be a runtime dependency, not a library dependency. This is more semantically accurate. vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Questions on dependencies
Peter, You would add those to the build dependencies with depends_build-append. I haven't installed myself, but I'm guessing they aren't too large, so if that's the case, I wouldn't have an issue with that. Blair On 10/31/13 12:17 PM, Peter Danecek wrote: Blair, Thanks for the quick reply. I would have another one: It is a python package. I have some dependencies, which actually are not needed for package itself but only for testing. Testing is non done by the port itself. So I would have not included these dependencies, i.e. `py-nose`, `py-pep8`, `py-mock`, but leave it to the user to install these if he wants to run the tests. Is this okay like this? Thanks! ~petr On Oct 31, 2013, at 20:08 , Blair Zajac wrote: On 10/31/13 11:54 AM, Peter Danecek wrote: Hi all, I'm somewhat puzzled with the dependencies of some ports, and I realise the I lack some basic understanding. (1) py-cython From what I understand, build dependencies are required during the build, but can be removed later. Also they are not required for installation of prebuilt packages. But I have no clear idea if `py-cython` is a build dependency or a lib dependency. Looking through the existing ports, I find both. We use Cython for an internal app but I've only seen it used as a build dependency. It could be that other ports could switch. If you're working on a new port, try making it a build dependency and switching to a lib if its needed at runtime. Is `py??-cython` required after the build? (2) python package dependencies Intuitively, I would say that most python package dependencies were lib dependencies. But they actually may install without, right? So is it okay to declare them lib dependencies or might it be better to make them runtime dependencies? lib is a runtime dependency. (3) What exactly makes a lib a dependency in Macports? I have the situation that some software depend on some library, its headers are included it is linked against it. Okay, here the situation is clear. But this lib may again depend on other libs, but my software does not directly reference/call these libraries. (It may need to link against it, not completely clear to me). Is this library a dependency for Macports or would I rely on the fact, that the library I am referencing directly, would have these other libraries as dependencies? MacPorts can support transitive dependencies (that is, not listing the dependencies of your dependencies), but in practice we commonly list those dependencies if they are picked up at build time by port. The reason to do this is to ensure the transitive dependency is not removed if the intermediate dependency is removed. Regards, Blair -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies Subversion training, consulting and support http://www.orcaware.com/svn/ ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Questions on dependencies
Blair, Thanks for the quick reply. I would have another one: It is a python package. I have some dependencies, which actually are not needed for package itself but only for testing. Testing is non done by the port itself. So I would have not included these dependencies, i.e. `py-nose`, `py-pep8`, `py-mock`, but leave it to the user to install these if he wants to run the tests. Is this okay like this? Thanks! ~petr On Oct 31, 2013, at 20:08 , Blair Zajac wrote: > On 10/31/13 11:54 AM, Peter Danecek wrote: >> >> Hi all, >> >> I'm somewhat puzzled with the dependencies of some ports, and I realise the >> I lack some basic understanding. >> >> (1) py-cython >> >> From what I understand, build dependencies are required during the build, >> but can be removed later. Also they are not required for installation of >> prebuilt packages. But I have no clear idea if `py-cython` is a build >> dependency or a lib dependency. Looking through the existing ports, I find >> both. > > We use Cython for an internal app but I've only seen it used as a build > dependency. It could be that other ports could switch. If you're working on > a new port, try making it a build dependency and switching to a lib if its > needed at runtime. > >> Is `py??-cython` required after the build? >> >> (2) python package dependencies >> >> Intuitively, I would say that most python package dependencies were lib >> dependencies. But they actually may install without, right? So is it okay to >> declare them lib dependencies or might it be better to make them runtime >> dependencies? > > lib is a runtime dependency. > >> >> (3) What exactly makes a lib a dependency in Macports? >> >> I have the situation that some software depend on some library, its headers >> are included it is linked against it. Okay, here the situation is clear. But >> this lib may again depend on other libs, but my software does not directly >> reference/call these libraries. (It may need to link against it, not >> completely clear to me). Is this library a dependency for Macports or would >> I rely on the fact, that the library I am referencing directly, would have >> these other libraries as dependencies? > > MacPorts can support transitive dependencies (that is, not listing the > dependencies of your dependencies), but in practice we commonly list those > dependencies if they are picked up at build time by port. The reason to do > this is to ensure the transitive dependency is not removed if the > intermediate dependency is removed. > > Regards, > Blair > 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: Questions on dependencies
On 10/31/13 11:54 AM, Peter Danecek wrote: Hi all, I'm somewhat puzzled with the dependencies of some ports, and I realise the I lack some basic understanding. (1) py-cython From what I understand, build dependencies are required during the build, but can be removed later. Also they are not required for installation of prebuilt packages. But I have no clear idea if `py-cython` is a build dependency or a lib dependency. Looking through the existing ports, I find both. We use Cython for an internal app but I've only seen it used as a build dependency. It could be that other ports could switch. If you're working on a new port, try making it a build dependency and switching to a lib if its needed at runtime. Is `py??-cython` required after the build? (2) python package dependencies Intuitively, I would say that most python package dependencies were lib dependencies. But they actually may install without, right? So is it okay to declare them lib dependencies or might it be better to make them runtime dependencies? lib is a runtime dependency. (3) What exactly makes a lib a dependency in Macports? I have the situation that some software depend on some library, its headers are included it is linked against it. Okay, here the situation is clear. But this lib may again depend on other libs, but my software does not directly reference/call these libraries. (It may need to link against it, not completely clear to me). Is this library a dependency for Macports or would I rely on the fact, that the library I am referencing directly, would have these other libraries as dependencies? MacPorts can support transitive dependencies (that is, not listing the dependencies of your dependencies), but in practice we commonly list those dependencies if they are picked up at build time by port. The reason to do this is to ensure the transitive dependency is not removed if the intermediate dependency is removed. Regards, Blair ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Questions on dependencies
Hi all, I'm somewhat puzzled with the dependencies of some ports, and I realise the I lack some basic understanding. (1) py-cython From what I understand, build dependencies are required during the build, but can be removed later. Also they are not required for installation of prebuilt packages. But I have no clear idea if `py-cython` is a build dependency or a lib dependency. Looking through the existing ports, I find both. Is `py??-cython` required after the build? (2) python package dependencies Intuitively, I would say that most python package dependencies were lib dependencies. But they actually may install without, right? So is it okay to declare them lib dependencies or might it be better to make them runtime dependencies? (3) What exactly makes a lib a dependency in Macports? I have the situation that some software depend on some library, its headers are included it is linked against it. Okay, here the situation is clear. But this lib may again depend on other libs, but my software does not directly reference/call these libraries. (It may need to link against it, not completely clear to me). Is this library a dependency for Macports or would I rely on the fact, that the library I am referencing directly, would have these other libraries as dependencies? Thanks for clarification! ~petr smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
