Can I use variable ${perl5.lib} in portfiles? I could just try it but I'm curious and I don't have time to test it right now. If so I can add it to the port man page after x11prefix in the RUNTIME VARIABLES section. Mark
On Jan 26, 2007, at 9:17 AM, Mark Duling wrote:
Can I use variable ${perl5.lib} in portfiles? I could just try it but I'm curious and I don't have time to test it right now. If so I can add it to the port man page after x11prefix in the RUNTIME VARIABLES section.
It's set in the perl5 group code, so you can only use it in portfiles that make use of the perl group code. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
"Daniel J. Luke" <dluke@geeklair.net> on Friday, January 26, 2007 at 6:48 AM -0800 wrote:
Can I use variable ${perl5.lib} in portfiles? I could just try it but I'm curious and I don't have time to test it right now. If so I can add it to the port man page after x11prefix in the RUNTIME VARIABLES section.
It's set in the perl5 group code, so you can only use it in portfiles that make use of the perl group code.
Oh right. I should have known that. Well in a non-perl port, I guess I could use perl -V system calls to get it in a non-hardcoded way since I don't want to update a port for a new perl release. perl -V:sitelib sitelib='/opt/local/lib/perl5/site_perl/5.8.8'; perl -V:sitearch sitearch='/opt/local/lib/perl5/site_perl/5.8.8/darwin-2level'; Why is it so little is in sitelib (I have one file RRDp.pm) and so much is in sitearch? Mark
On Jan 26, 2007, at 3:15 PM, Mark Duling wrote:
"Daniel J. Luke" <dluke@geeklair.net> on Friday, January 26, 2007 at 6:48 AM -0800 wrote:
Can I use variable ${perl5.lib} in portfiles? I could just try it but I'm curious and I don't have time to test it right now. If so I can add it to the port man page after x11prefix in the RUNTIME VARIABLES section.
It's set in the perl5 group code, so you can only use it in portfiles that make use of the perl group code.
Oh right. I should have known that. Well in a non-perl port, I guess I could use perl -V system calls to get it in a non-hardcoded way since I don't want to update a port for a new perl release.
perl -V:sitelib sitelib='/opt/local/lib/perl5/site_perl/5.8.8';
perl -V:sitearch sitearch='/opt/local/lib/perl5/site_perl/5.8.8/darwin-2level';
Why is it so little is in sitelib (I have one file RRDp.pm) and so much is in sitearch?
Macports should be installing stuff into vendor_perl (that's what perl5.lib gets set to). ... but IIRC sitearch is where compiled modules go (ie C-based XS modules) and pure-perl stuff goes into site_perl (so that if you share your perl over NFS, for instance, you can use one directory hierarchy for multiple architectures, I think). -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
On Jan 26, 2007, at 3:15 PM, Mark Duling wrote:
Can I use variable ${perl5.lib} in portfiles? I could just try it but I'm curious and I don't have time to test it right now. If so I can add it to the port man page after x11prefix in the RUNTIME VARIABLES section.
It's set in the perl5 group code, so you can only use it in portfiles that make use of the perl group code.
Oh right. I should have known that. Well in a non-perl port, I guess I could use perl -V system calls to get it in a non-hardcoded way since I don't want to update a port for a new perl release.
Is there a way to get the results of an external command into a variable in a portfile? I have a port that needs to set the path to 'perl -V:sitearch'. I can hardcode it for perl 5.8.8 for now, but I don't want to have to update it for every perl update. It seems that the freebsd ports sytem has access for perl variables even for non-perl ports. Would that be easy to hack onto MaPorts? It would be nice but I don't know the pros and cons. Mark
On Jan 27, 2007, at 8:16 PM, Mark Duling wrote:
Is there a way to get the results of an external command into a variable in a portfile?
Yep. Take a look at PYTHON_PATH in the subversion-pythonbindings port for one way to do this sort of thing.
It seems that the freebsd ports sytem has access for perl variables even for non-perl ports. Would that be easy to hack onto MaPorts? It would be nice but I don't know the pros and cons.
I don't think it's worthwhile to add it to base/ since it's relatively easy for the portfiles get their own information if they need it. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
"Daniel J. Luke" <dluke@geeklair.net> on Sunday, January 28, 2007 at 11:46 AM -0800 wrote:
Is there a way to get the results of an external command into a variable in a portfile?
Yep.
Take a look at PYTHON_PATH in the subversion-pythonbindings port for one way to do this sort of thing.
Ok, will do. Thanks.
It seems that the freebsd ports sytem has access for perl variables even for non-perl ports. Would that be easy to hack onto MaPorts? It would be nice but I don't know the pros and cons.
I don't think it's worthwhile to add it to base/ since it's relatively easy for the portfiles get their own information if they need it.
Perhaps there is another option, which did not occur to me until now. I put smokeping (the app for which I'd like to use ${sitearch}) in the net category, but really I suppose there is no reason why I couldn't categorize it as perl and net categories and just use the perl5 portgroup, then I'd have access to {sitearch}. It is a perl application, though it requires no compiling at all and is used to monitor networks. Is this valid reasoning? If so ... Could I just add "PortGroup perl5 1.0" to my portfile? If so should it be in dports/perl or is adding "perl" as a virtual or secondary category sufficient to use the perl5 portgroup? Mark
"Mark Duling" <mark.duling@biola.edu> on Sunday, January 28, 2007 at 2:03 PM -0800 wrote:
It seems that the freebsd ports sytem has access for perl variables even for non-perl ports. Would that be easy to hack onto MaPorts? It would be nice but I don't know the pros and cons.
I don't think it's worthwhile to add it to base/ since it's relatively easy for the portfiles get their own information if they need it.
Perhaps there is another option, which did not occur to me until now. I put smokeping (the app for which I'd like to use ${sitearch}) in the net category, but really I suppose there is no reason why I couldn't categorize it as perl and net categories and just use the perl5 portgroup, then I'd have access to {sitearch}. It is a perl application, though it requires no compiling at all and is used to monitor networks. Is this valid reasoning? If so ...
Could I just add "PortGroup perl5 1.0" to my portfile?
Ok, it works. Adding the 'PortGroup perl5 1.0' statement to my port allowed me to use the variable ${perl5.archlib}, just what I wanted. The only remaiing question is when I add the perl portgroup to the smokeping port, whether I should move the port to category dports/perl or leave it in dports/net with perl as a secondary category. Mark
On Jan 28, 2007, at 6:37 PM, Mark Duling wrote:
Ok, it works. Adding the 'PortGroup perl5 1.0' statement to my port allowed me to use the variable ${perl5.archlib}, just what I wanted. The only remaiing question is when I add the perl portgroup to the smokeping port, whether I should move the port to category dports/perl or leave it in dports/net with perl as a secondary category.
I don't think it matters if you use the group code in a non perl category. Its probably best if you (as the maintainer) decide which categories the port belongs to. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
On 28 Jan 2007, at 19:12, Daniel J. Luke wrote:
On Jan 28, 2007, at 6:37 PM, Mark Duling wrote:
Ok, it works. Adding the 'PortGroup perl5 1.0' statement to my port allowed me to use the variable ${perl5.archlib}, just what I wanted. The only remaiing question is when I add the perl portgroup to the smokeping port, whether I should move the port to category dports/perl or leave it in dports/net with perl as a secondary category.
I don't think it matters if you use the group code in a non perl category.
Its probably best if you (as the maintainer) decide which categories the port belongs to.
I personally feel that the language-specific groups (java, perl, python, etc) only really make sense as the primary group for bindings or extension to the language. If you have a network application/tool then I'd put it in the net group.
-- Daniel J. Luke +========================================================+ | *---------------- dluke@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 http://lists.macosforge.org/mailman/listinfo/macports-dev
Randall Wood rhwood@mac.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."
Randall Wood <rhwood@mac.com> on Sunday, January 28, 2007 at 5:25 PM -0800 wrote:
I personally feel that the language-specific groups (java, perl, python, etc) only really make sense as the primary group for bindings or extension to the language. If you have a network application/tool then I'd put it in the net group.
Makes sense. Thanks Randall and Daniel for the advice! I've managed to make almost effortless the installation of an otherwise difficult and confusing installation. MacPorts rules! Mark
participants (3)
-
Daniel J. Luke
-
Mark Duling
-
Randall Wood