module-build-general Mailing List for Module::Build (Page 177)
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general — General discussion about Module::Build project
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(24) |
Sep
(2) |
Oct
(18) |
Nov
(36) |
Dec
(17) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(3) |
Feb
(96) |
Mar
(82) |
Apr
(63) |
May
(90) |
Jun
(52) |
Jul
(94) |
Aug
(89) |
Sep
(75) |
Oct
(118) |
Nov
(101) |
Dec
(111) |
| 2004 |
Jan
(159) |
Feb
(155) |
Mar
(65) |
Apr
(121) |
May
(62) |
Jun
(68) |
Jul
(54) |
Aug
(45) |
Sep
(78) |
Oct
(80) |
Nov
(271) |
Dec
(205) |
| 2005 |
Jan
(128) |
Feb
(96) |
Mar
(83) |
Apr
(113) |
May
(46) |
Jun
(120) |
Jul
(146) |
Aug
(47) |
Sep
(93) |
Oct
(118) |
Nov
(116) |
Dec
(60) |
| 2006 |
Jan
(130) |
Feb
(330) |
Mar
(228) |
Apr
(203) |
May
(97) |
Jun
(15) |
Jul
(6) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Autrijus T. <aut...@au...> - 2003-03-06 03:50:58
|
On Tue, Feb 18, 2003 at 10:49:46PM -0600, Ken Williams wrote:
> I don't have a lot of experience designing mini-languages, but I'm=20
> thinking it should do at least the following:
>=20
> * Allow arbitrary boolean combinations of dependency on arbitrary
> versions of modules
>=20
> * Allow declarative branching based on perl version or OS
>=20
> * Allow dependency specification based on feature sets, similar
> to the way ExtUtils::AutoInstall groups things
>=20
> * Let the author specify *why* a certain dependency is necessary,
> especially in the case of optional dependencies
Below please find a sample of my current proposal of formalizing
EU::AI parameters into YAML so it can be written insite META.yml,
based on today's IRC discussion. I hope it to be self-descriptory.
The top-level "build_requires/recommends/requires" keys corresponds
with the -core feature in EU::AI parlance.
Comments welcome!
Thanks,
/Autrijus/
--- #YAML:1.0
build_requires:
Test::More: {}
recommends:
Acme::ComeFrom:
alternate:
Acme::ComeWith:
version: 0.05
reason: "I really likes it"
version: 0.02
requires:
Some::Module:
arch: MSWin32
perl: 5.6.0
version: 1.04
Other::Module:
version 1.53
arch: '!Solaris'
perl: 5.005
features:
- name: This is feature one
requires:
arch: MSWin32
Module::Foo:
perl: '<5.6.0'
version: 2.04
- name: Feature two
requires:
Lingua::ZH::TaBE: {}
recommends:
Lingua::EN::Inflect:
arch: '!MSWin32'
version: 3.03
|
|
From: <bu...@ye...> - 2003-03-06 00:54:47
|
<html>
<head>
<title>招标信息</title>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
</head>
<body bgcolor="#FFFFFF" text="#000000" leftmargin="0" topmargin="0">
<table width="610" border="0">
<tr>
<td colspan="2">
<div align="center"><a href="http://www.ye2000.com" target="_blank"><img src="http://www.ye2000.com/build/images/pop/mailbuild01.gif" width="468" height="60" border="0"></a></div>
</td>
</tr>
<tr>
<td bgcolor="#993333" colspan="2">
<div align="center"><font color="#FFFF00" size=3><strong><font color="#FFFFFF">2003/03/05
星期三</font></strong></font></div>
</td>
</tr>
<tr>
<td bgcolor="#FFCC99" height="6"><font color="#FFFF00" size="5"><strong><font size="3" color="#993333">◆◇◆特别推荐◆◇◆</font></strong></font></td>
<td width="18%" rowspan="2" valign="top" bgcolor="#FF0000">
<table width="100%" border="0" cellspacing="1" bgcolor="#FF0000" height="177">
<tr>
<td>
<div align="center"><font size="2"><b><font size="4" color="#FFFF00">企业推荐</font></b></font></div>
</td>
</tr>
<tr>
<td>
<div align="center"><b><font size="3"><a href="http://www.honeywell.com" target="_blank">Heneywell</a></font></b></div>
</td>
</tr>
<tr>
<td>
<div align="center"><b><font size="3"><a href="http://www.cchongda.com.cn/" target="_blank">长春鸿达</a></font></b></div>
</td>
</tr>
<tr>
<td>
<div align="center"><b><a href="http://www.jiale.com" target="_blank"><font size="3">佳乐电器</font></a></b></div>
</td>
</tr>
<tr>
<td height="4">
<p align="center"><b><font size="3"><a href="http://www.lianteng.com/" target="_blank">上海联腾</a></font></b></p>
</td>
</tr>
<tr>
<td>
<div align="center"><b><font color="#FFFF00" size="3">九利科技</font></b></div>
</td>
</tr>
<tr>
<td>
<div align="center"><b><font size="3" color="#FFFF00"><a href="http://www.abb.com.cn" target="_blank">ABB</a></font></b></div>
</td>
</tr>
<tr>
<td>
<div align="center"><b><font color="#FFFF00" size="3"><a href="http://www.e-wellsun.com" target="_blank">上海元上</a></font></b></div>
</td>
</tr>
<tr>
<td>
<div align="center"><b><font size="3"><font color="#FFFF00"><a href="http://www.cxit.com.cn" target="_blank">成星自动化</a></font></font></b></div>
</td>
</tr>
<tr>
<td>
<div align="center"><b><font size="3"><font color="#FFFF00"><a href="http://www.sunwave.cc" target="_blank">圣威尔</a></font></font></b></div>
</td>
</tr>
<tr>
<td>
<div align="center"><b><a href="http://www.szake.com" target="_blank">艾康电子</a></b></div>
</td>
</tr>
<tr>
<td height="45">
<div align="center"><b><font color="#0000CC">虚位以待</font></b></div>
</td>
</tr>
</table>
</td>
</tr>
<tr>
<td height="804" valign="top" bordercolor="#00FF00">
<div align="center">
<table width="100%" border="1">
<tr>
<td height="19" bordercolor="#00FF00">
<div align="left">综合布线招标公告
<p>本信息来源于中国项目采购库www.cepn.com </p>
<p>招标编号： NXITC02157、NXITC02158<br>
开标时间： 2003-03-27<br>
所属行业： 电梯设备、综合布线<br>
标讯类别： 公开招标<br>
资金来源： <br>
招标代理： 宁夏国际招标有限公司<br>
业主名称： <br>
所属地区： 宁夏<br>
招标内容：</p>
<p> 宁夏国际招标有限公司受宁夏政府采购办公室委托，就所需电梯设备及综合布线进行公开招标，欢迎合格的供应商前来投标。 <br>
1、招标编号：NXITC02157、NXITC02158 <br>
2、招标内容：电梯设备、综合布线 <br>
3、标书发售：2003年3月4日-2003年3月27日 <br>
每天上午8：30-12：00 下午14：30-18：00 <br>
标书售价：每份人民币300元（标书售后不退） <br>
发售地点：宁夏国际招标有限公司（一处） <br>
地 址：银川市进宁北街24号 <br>
收款单位：宁夏区设备招标局 <br>
开 户 行：建行银川市文化西街支行 <br>
帐 号：2269001102 <br>
4、截止投标时间：2003年3月19日 <br>
5、技术答疑时间：2003年3月20日 <br>
6、开 标 时 间： 2003年3月27日 <br>
联 系 人：孙志涛 <br>
联系电话：0951-5053445 5053965（传真） </p>
<p>长沙市八方小区智能化工程 </p>
<p>本信息来源于中国项目采购库www.cepn.com </p>
<p>招标编号： GXTC-2003HN015<br>
开标时间： 2003-03-25<br>
所属行业： 网络通讯计算机,市政房地产建筑<br>
标讯类别： 国内招标信息<br>
资金来源： 国内政府资金<br>
招标代理： 湖南国信招标咨询有限责任公司<br>
业主名称： 长沙市经发房地产公司<br>
所属地区： 湖南省<br>
招标内容：</p>
<p> 湖南国信招标咨询有限责任公司受长沙市经发房地产公司的委托，对下列工程及服务进行国内公开招标，现邀请合格的投标人参加投标。
<br>
1、招标工程名称： <br>
长沙市八方小区一期A区智能化工程建设 <br>
A包: <br>
1）负责A区弱电设计、及预埋线路的施工； <br>
2）闭路电视监控系统； <br>
3）小区“一卡通”系统； <br>
4）紧急广播与背景音乐系统； <br>
5）停车场管理系统； <br>
6）周界防范系统。 <br>
B包： <br>
1）可视对讲及防盗门控系统； <br>
2）家居安防系统； <br>
3）巡更系统； <br>
4）电子公告牌系统。 <br>
C包： <br>
1）远程抄表系统； <br>
2）燃气安全监控系统； <br>
3）远程用电控制系统。 <br>
D包： <br>
1）计算机宽带网络系统； <br>
2）有线电视及卫星电视系统； <br>
3）电话系统； <br>
2、投标人资格要求： <br>
2.1A包、B包投标人要求同时具备《安防资质证书》、《信息工程资质证书》、《智能化工程承接资质证书》，C包投标单位要求同时具备《安防资质证书》、《智能化工程承接资质证书》，D包投标单位要求具备广电部门的设计、施工证书。
<br>
2.2各包投标人至少承接过两个以上的超过1200户的同类型的工程。 <br>
3、招标文件发售时间、地点： <br>
招标文件从即日起至2003年3月21日，每天8:00～12:00,14:30～17:30(北京时间，节假日除外)在湖南国信招标咨询有限责任公司发售。标书售价A包400元；B、C、D包每包300元，标书按包发售；若邮购,需加付EMS费60元人民币。标书售后不退。投标人可以分包投标。
<br>
4、投标截止时间和开标时间： <br>
投标截止时间：2003年3月25日上午9:30(北京时间)。 <br>
开标时间：2003年3月25日上午9:30(北京时间)。 <br>
投标文件递交至湖南国信招标咨询有限责任公司，逾期收到或未按照招标文件要求提供投标保证金的投标恕不接受。 <br>
5、开标地点：长沙市五一中路90号粮贸大厦19楼。 <br>
湖南国信招标咨询有限责任公司 <br>
地址：长沙市五一中路90号粮贸大厦14楼 <br>
<br>
<br>
招标代理：湖南国信招标咨询有限责任公司 <br>
业主名称：长沙市经发房地产公司 <br>
地 址：长沙市五一路90号粮贸大厦14楼 <br>
邮 编：410011 <br>
联系人 ：孙占海、周敏 <br>
电 话：0731-2567503、4450910 <br>
传 真：0731-4424541 <br>
电子邮件： <br>
国内银行：中信实业银行长沙分行五一支行 <br>
国内银行帐号：7401310182600022303；户名：湖南国信招标咨询有限责任公司 </p>
<p></p>
<p><br>
火灾报警系统招标 </p>
<p>本信息来源于中国项目采购库www.cepn.com </p>
<p>招标编号： 62242100030116002<br>
开标时间： 2003-03-18<br>
所属行业： 机械电子电器,医疗卫生<br>
标讯类别： 国内招标信息<br>
资金来源： 国内政府资金<br>
招标代理： 甘肃瑞凯监理公司<br>
业主名称： 甘肃扶正药业科技股份有限公司<br>
所属地区： 甘肃省<br>
招标内容：</p>
<p> 甘肃扶正药业科技股份有限公司“贞芪扶正中药产品高技术产业化示范工程”工程及设备项目第二阶段国内公开招标，现邀请合格的单位参加投标。
<br>
1、招标共分6个标段，各标段详细情况如下： <br>
(1)工艺安装施工标段：厂区内所有工艺管道、设备、保温安装调试； <br>
(2)电气、仪表安装施工标段：厂区内所有电气、仪表、设备线缆安装调试； <br>
(3)电气、仪表设备采购(详见招标文件)； <br>
(4)空调净化系统设备制造及安装调试； <br>
(5)火灾报警系统标段：所有设备采购及安装调试； <br>
(6)检验仪表标段。 <br>
注：以上工程内容及各设备的规格型号及技术参数详见招标文件。 <br>
工程及设备交货地点：贞氏扶正中药产品高技术产业化示范工程工地(定西县？口镇开发区) <br>
2、资金来源：银行货款、企业自筹 <br>
3、投标资格及报名条件：必须是独立法人，财务状况良好的施工企业和设备制造商。购买招标文件需携带：单位介绍信、法人授权书、被委托人身份证原件、设备制造许可证、施工资质、营业执照(副本)、资质证书。
<br>
4、招标文件售价：每套人民币800元，售后不退。 <br>
5、报名时间、地点：2003年2月28日至3月2日，每日8：30至17：50(北京时间)，甘肃定西公路宾馆。 <br>
6、出售招标文件时间、地点：2003年3月2日，甘肃定西扶正制药有限公司项目办。 <br>
7、投标截止时间及开标时间、开标地点： <br>
2003年3月18日上午8：30时(北京时间) <br>
开标地点：甘肃定西工程交易中心二楼交易大厅。 <br>
<br>
招标单位：甘肃扶正药业科技股份有限公司 <br>
地址：定西县交通路305号 <br>
邮编：743000 传真：0932-8213468 <br>
电话：13519024014 <br>
联系人：姚华 杨克恭 杨克谦 <br>
<br>
<br>
招标代理：甘肃瑞凯监理公司 <br>
业主名称：甘肃扶正药业科技股份有限公司 <br>
地 址：甘肃省定西县交通路305号 <br>
邮 编：743000 <br>
联系人 ：姚华、杨克恭、杨克谦 <br>
电 话：13519024014 </p>
<p><br>
球型一体化摄像机、现场应急监控系统警用设备招标 </p>
<p>本信息来源于中国项目采购库www.cepn.com </p>
<p>招标编号： 0724-02010334<br>
开标时间： 2003-03-25<br>
所属行业： <br>
标讯类别： 国内公开招标<br>
资金来源： <br>
招标代理： 广东机械进出口国际招标有限公司<br>
业主名称： 广州市政府采购中心<br>
所属地区： 广州市<br>
招标内容：</p>
<p> 广东机械进出口国际招标有限公司（以下简称“招标机构”）受广州市政府采购中心委托进行国内公开招标，邀请合格投标人就以下设备及有关服务提交密封投标：
<br>
1．招标编号：0724-02010334 <br>
2．项目名称：广州市政府采购警用设备招标项目 <br>
3．招标设备名称及数量： <br>
包号 招标设备名称 数量 <br>
1 球型一体化摄像机 2台 <br>
2 现场应急监控系统 1套 <br>
详细技术规范请参阅招标文件中的用户需求书。投标人可选择其中一个包进行投标但必须提供包内全部设备的投标报价，缺漏项报价将视为无效投标。
<br>
4．交货时间：合同签订后20天内。 <br>
5．交货地点：广州市用户指定地点 <br>
6．投标人资格: 投标商必须先登记获得广州市政府采购供应商[lily1]资格 方可到招标机构购买招标文件。并按要求提交资料审验，
该项工作由广州市政府采购中心审核部负责，咨询电话： 83581486，83581759，83495135 <br>
7．招标文件由招标机构发售。有兴趣的投标人可从 2003年3月4日至2003年3月24日9:00时至16:30时(北京时间)到以下地址购买招标文件，本招标文件每套售价为150元人民币，售后不退.
<br>
<br>
广东机械进出口国际招标有限公司 <br>
广州市东风东路726号16楼 <br>
电话：86 20 87673245，87673254，87768198 <br>
传真：86 20 87768283 <br>
<br>
国内邮购标书者应加50元人民币作特快专递费。招标机构将用航空快递及时寄去招标文件，但在任何情况下招标机构对邮寄过程中发生的迟交或遗失都不承担责任。
<br>
有投标书必须附有一份金额为投标总价2% 的投标保证金。投标书及投标保证金必须在2003年3月25日当天上午投标截止时间10:00时（北京时间）之前由投标人授权代表亲自送达下列地点，招标机构将不接受其它形式的投标：
<br>
8．开标时间：2003年3月25日上午10:00时(北京时间) <br>
9．开标地点：广州市政府采购中心[p6]会议室 <br>
10．招标机构将不负责投标人准备标书和递交标书所发生的任何成本或费用。 <br>
11．有关此次招标邀请之事宜， 可按下列地址以书面或传真的形式向招标机构查询： <br>
地 址： 广州市东风东路726号16楼 <br>
电 话： (8620) 87673245，87673254，87768198 <br>
传 真： (8620) 87768283 <br>
网 址：www.gmgit.com <br>
联系人：刘丹，张惠玲，梁咏瑜 <br>
开户银行：中国银行广东省分行 <br>
帐 号：800105776108091001 </p>
</div>
<p align="left"><font size="2">谈谈你的意见 E-mail:<a href="mailto:bu...@ye...">bu...@ye...</a></font></p>
</td>
</tr>
</table>
<font size="2"><a href="http://www.ye2000.com" target="_blank"><img src="http://www.ye2000.com/build/images/pop/mailbuild01.gif" width="468" height="60" border="0"></a>
</font></div>
</td>
</tr>
<tr bgcolor="#009966">
<td colspan="2" height="56"><b><font color="#FFFFFF">敬告读者:</font></b><font color="#FFFFFF">
为了保证您的疑问或建议能够得到及时处理，请不要使用返信方式，以免您的问题被延误。欢迎订阅杂志，见附件，谢谢合作！回信地址: <a href="mailto:bu...@ye...">bu...@ye...</a></font></td>
</tr>
<tr valign="top">
<td colspan="2" height="2">
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td class="ziti5" height="13" colspan="2"> </td>
</tr>
<tr>
<td class="ziti1" colspan="2"><img src="http://www.kingland.net.cn/zhiye/znrd/znruodian_zhbx_01.gif" width="500" height="100"></td>
</tr>
<tr>
<td colspan="2" ><img src="http://www.kingland.net.cn/zhiye/znrd/znruodian_aqff_06.gif" width="500" height="18"></td>
</tr>
<tr>
<td class="ziti1" colspan="2"> 在经济飞速发展的信息社会里，一套优质、完善、先进的布线系统，不仅关系到公司的信息技术战略，而且还关系到企业的整体发展。<br>
金伦科技推出标准的端到端的结构化布线系统，从五类、超五类、增强型五类、六类、超六类，直到七类系列。结构化布线系统具有易于设计、安装、维护、移动、扩展等特点。另外，我们还提供15年以上的部件保修期及终身系统保用证明，确保我们每一个用户不仅可以充分享受高速信息公路的畅快，而且还可以增强每个用户迎接未来挑战的决心和信心。
<br>
金伦科技是NORDX/CDT IBDN、ALCATEL综合布线系统认证集成商，拥有多名IBDN、ALCATEL、AVAYA、IBM系统认证工程师，做过上百个工程，具有丰富的工程管理和施工经验，并为用户提供优质的后期维护服务。
</td>
</tr>
<tr>
<td colspan="2"><img src="http://www.kingland.net.cn/zhiye/znrd/znruodian_zhbx_05.gif" width="250" height="18"></td>
</tr>
<tr>
<td colspan="2" class="ziti2" height="8"> </td>
</tr>
<tr>
<td colspan="2" class="ziti2"><img src="http://www.kingland.net.cn/zhiye/znrd/znruodian_zhbx_02.gif" width="350" height="35"></td>
</tr>
<tr>
<td colspan="2" class="ziti1"> 丽特网络的IBDN综合布线系统是标准的端到端结构化布线系统。该系统可根据用户的机构改变或技术要求随时进行调整，从而满足用户不断增长的对可靠性、工作效率和传输数据的要求。IBDN产品质量远远超过业界标准，并且易于设计、安装和维护，在恶劣建筑环境中也能保持性能良好。IBDN质量认证系统则为用户提供了长期可靠运作的保证。</td>
</tr>
<tr>
<td colspan="2"><img src="http://www.kingland.net.cn/zhiye/znrd/znruodian_zhbx_03.gif" width="350" height="40"></td>
</tr>
<tr>
<td colspan="2" class="ziti1"> 耐克森（原阿尔卡特）综合布线系统以其先进的技术、精湛的生产工艺及ISO9001体系保证其产品的高品质。其产品性能远远高于国际标准的有关规定。耐克森作为一个系统生产厂商，特向用户提供链路和信道的性能认证和质量保证。提供独一无二的终生质量保证！</td>
</tr>
<tr>
<td colspan="2"><img src="http://www.kingland.net.cn/zhiye/znrd/znruodian_zhbx_04.gif" width="350" height="40"></td>
</tr>
<tr>
<td colspan="2"> </td>
</tr>
</table></td>
</tr>
<tr valign="top">
<td colspan="2" height="238">
<table width="100%">
<tr>
<td width="20%" height="238" rowspan="2" valign="top">
<table border="0" height="251" width="100%">
<tr>
<td bgcolor="#33FF00" height="5">
<div align="center"><strong>公告</strong></div>
</td>
</tr>
<tr>
<td bgcolor="#33FF00" height="39">
<div align="left">
<table width="98%"
border=0 align=center cellpadding=0 cellspacing=0>
<tbody>
<tr>
<td width="36%" bgcolor="#33FF00" class=td1> <marquee id=marq onMouseOver=this.stop() dataformatas=html
onMouseOut=this.start() scrollamount=1 scrolldelay=1
direction=up width=152 height=200> <font size="2">为了加强客户之间的交流与合作，更快地了解行业动态，节省你每日的上网浏览，《国际智能建筑》将向你及时发送相关行业资料，敬请关注每天的供求信息和招标信息</font><a href="http://www.ye2000.com">ye2000</a><font size="2">等着你！从现在开始，你不用出门也能买(到)卖(掉)您的产品了。
<br>
<font color="#33FF00">亚视</font>亚视通资讯新闻中心 </font> </marquee></td>
</tr>
</tbody>
</table>
</div>
</td>
</tr>
<tr>
<td bgcolor="#FFFFCC" height="2"> </td>
</tr>
</table>
</td>
<td width="22%" valign="top" height="238" rowspan="2">
<table width="12%" border="0">
<tr>
<td valign="top" bgcolor="#FF0000">
<div align="center"><strong>通告</strong></div>
</td>
</tr>
<tr>
<td valign="top" bgcolor="#FF0000" height="47"><font size="2">为了加强智能建筑行业的发展和交流，我网即起至5月31日止，全免费为你登企业动态、供求信息和新产品发布。祝新老客户羊年大吉！</font></td>
</tr>
<tr>
<td valign="top" bgcolor="#FF0000">
<p><font size="2">联系方式：<br>
区号（0755）<br>
电话:83690456<br>
传真:83690435<br>
E-mail：<br>
</font><a href="mailto:build@ye2000. com">bu...@ye...</a>
</p>
</td>
</tr>
</table>
</td>
<td width="58%" valign="top" bgcolor="#993333" height="22"><b><font size="2" color="#FFFFFF">◆◆</font><font color="#FFFFFF">今日推荐企业</font></b><font color="#FFFFFF">：<font size="3">深圳市金伦科技有限公司</font></font>
</td>
</tr>
<tr>
<td width="58%" valign="top" height="215"><font color="#FFFF00"><b></b></font>深圳市金伦科技有限公司成立于1993年。在IT业日新月异的今天，无论是电信传统的语音通信，还是现代的数据通信，都将"殊途同归"。金伦科技正是将数据、语音、视频多种业务一体化，全方位为用户提供专业服务的公司。目前，公司除代理知名品牌TOSHIBA、SAMSUNG、ALCATEL、ERICSSON、CISCO、NORTEL、AWAYA、D-Link等通讯及网络产品外，在产品研究开发及系统集成方面也取得了显著成就。金伦语音产品中电脑话务员、语音信箱、VoIP网关在国内市场享有较高知名度，系统集成从企业网络整体解决方案到智能大厦、智能小区的弱电总包；从整体规划设计、到施工、培训、维护，为用户提供一条龙的专业、系统、完善的优质服务。
<br>
<br>
公司在北京、上海、广州、东莞、成都、沈阳、南京、杭州、西安、福州、海口等十几个城市设有分公司及办事处，员工三百余人，覆盖全国的经销商二千余家。我们相信，凭借公司的实力及对市场的深刻理解，以其先进的经营理念、卓越的产品质量及完善的客户服务，一定会"做得更好,永无止境"。
<a href="http://www.kingland.net.cn/" target="_blank">http://www.kingland.net.cn/</a><br>
</td>
</tr>
</table>
</td>
</tr>
</table>
<table width=610 border="0">
<tr bgcolor="#33FFFF">
<td width="14%" height="20">
<div align="center"><strong><font color="#000000">虚位以待</font></strong></div>
</td>
<td width="86%"><strong><font color="#FF0000">新闻信息/广告投稿</font>：</strong><br>
电<font color="#33FFFF">话</font>话：0755-83690456<font color="#33FFFF"> 生生生生生</font>传<font color="#33FFFF">生</font>真：0755-83690435<br>
联系人：谢生<font color="#33FFFF">生</font><font color="#33FFFF">生</font><font color="#33FFFF">
陈生生 陈生生生</font>E-mail: bu...@ye...<br>
<strong>http</strong> ://www.ye2000.com </td>
</tr>
</table>
</body>
</html>
|
|
From: Ken W. <ke...@ma...> - 2003-03-04 20:48:10
|
On Tuesday, March 4, 2003, at 02:38 PM, Bri...@AR... wrote: > Ken - > > I downloaded and installed Module::Build 0.16 on my Win32 ActiveState > Perl > 5.6 without a hitch. Great work! Much smoother than the 0.15 > installation I conversed with you about last month. > > I've attached a PPM package for Win32 ActiveState Perl 5.6 > installation of > Module::Build 0.16 -- Feel free to use it and distribute if you like. > Note, my crappy mailer (Lotus Notes) will probably munge the name to > 8.3 - > it's originally 'Module-Build-0.16_ppm.tar.gz' > > I'm not sure what's involved (too busy to dig in right now), but > supporting a build target of 'ppd' mirroring the functionality of the > existing MakeMaker system will ease generation of these package for > future > users of Module::Build. Awesome, thanks for testing and for the PPM. I'm quite interested in supporting a 'ppd' action (both for M::B itself and for other modules built using M::B), so at some point I'll want to figure out how to do this properly. How did you create this one? Where's the best place for me to put the PPM tarball? I can certainly upload it to my CPAN directory, should I also see about getting it in the ActiveState repository or something? -Ken |
|
From: Randy W. S. <Ra...@Th...> - 2003-03-01 21:33:20
|
Calls the pl2bat utility (distributed with the perl core) on perl scripts which adds a short batch startup script to the file which invokes perl. As per MakeMaker both the .pl and the new .bat file will be installed. See the documentation in <perl-source>/win32/bin/pl2bat.pl and in the <perl-source>/README.win32 file in the section 'Usage Hints' - 'Running Perl Scripts' for details. Randy. |
|
From: Randy W. S. <Ra...@Th...> - 2003-03-01 21:18:07
|
Bareword "Data::Dumper" not allowed while "strict subs" in use at Build.PL line 11. etc. I get this on perl, v5.8.0 built for MSWin32-x86-multi-thread compiled with gcc-2.95.2, msvc-6.0, and on ActiveState perl build 804. This patch just adds single quotes around all keys. Alternative is to remove 'use strict'. Randy. |
|
From: Randy W. S. <Ra...@Th...> - 2003-03-01 21:07:09
|
>> In my notes, I put down the names of two of the files: 'Sample.pm' &
>> 'MANIFEST'. There may be others; I admit that I mostly ignored the
>> errors at the time because I was focusing on the compiling/linking
>> tests and I didn't want to get sidetracked. I'll take a closer look at
>> this.
>
>
> Does anything change if you add an explicit close() in
> version_from_file() ? I think that's the only place Sample.pm would be
> opened.
>
> For the MANIFEST, all that code is buried in ExtUtils::Manifest, so
> it'll be harder to fix, probably.
>
It appears that all of the problems come from ExtUtils::Manifest. I have
not completely narrowed down the problem there, but I suspect it is a
bug in Perl's link() implementation on MSWin32 (which EU::Manifest only
attempts on Windows NT variants, and not Windows 9x). The problem is
eliminated by changing the call to EU::Manifest::manicopy() in
M::B::Base::ACTION_distclean() so that the last parameter is 'cp'
instead of 'best'. This of course is not the correct solution, nor is
copying the entire sub to Windows.pm just to change one line. Maybe an
option can be set in $self->{config} to indicate whether link()ing
should be avoided: The constructor in Base.pm could set a default,
allowing links, and any subclass that needed to could change it. Then
the line in ACTION_distclean() could be changed to pass the appropriate
flag to manicopy() based on the config option???
>> This is something else I wanted to revisit. If I'm not mistaken this
>> may actually be a Perl bug that was in 5.6.1, but has since been
>> fixed. At least I think I remember some problem being fixed in the
>> system() call.
>
> Oh yuck. =( Well, let me know if you find anything, but I hope you don't!
I've tried a few times to reproduce the problem with the system() call,
but have been unsuccessfull. I'm sure I have run through the tests a few
thousand times (using scripts, not manually ;) using various compilers
and version of perl and this has never resurfaced, so I think it
unlikely it will come up again; I just wish I knew from whence it came
and to whither it went.
Randy.
|
|
From: Ken W. <ke...@ma...> - 2003-02-28 15:40:58
|
On Friday, February 28, 2003, at 02:51 AM, クリックシティー wrote: > 突然のメール失礼いたします。 > 私、クリックシティーの阿部と申します。 Um, so, looks like I need to turn on subscriber-only posting to this list (with approval). Can't for the life of me figure out how to do that in the MailMan interface, though, does anybody know? -Ken |
|
From:
<cli...@ai...> - 2003-02-28 08:51:41
|
突然のメール失礼いたします。 私、クリックシティーの阿部と申します。 今回貴サイトを拝見させて頂いて大変内容もよく素晴らしいサイトだと感じられました。 是非とも弊社の広告を掲載して頂きたく思いメールさせて頂きました。 始めたばかりのサイトオーナー様でも気軽に申し込み出来ますので収入ＵＰに最適です。 ※携帯専用の広告ですのでＰＣサイトオーナー様は登録する事が出来ません御了承ください。 ■■ 特徴 ■■■■■■■■■■■■■■■■■■■■■■■ ■ ■・驚きの１クリック２０円〜５０円の高額クリック単価。 ■ ■・業界初！３千円からの広告料金のお支払い ■ ■・広告報酬は業界最速の月末締め翌月末日にお支払い。 ■ ■・お申し込み受付後２４時間以内に始める事が出来ます。 ■ ■・クリック数がリアルタイムで確認できる安心のシステム。 ■ ■・自由に選べる広告タグ。 ■ ■■ 特徴 ■■■■■■■■■■■■■■■■■■■■■■■ ■ ■・業界初！３千円からの広告料金のお支払い ■ ■・驚きの１クリック２０円〜５０円の高額クリック単価。 ■ ■・広告報酬は業界最速の月末締め翌月末日にお支払い。 ■ ■・お申し込み受付後２４時間以内に始める事が出来ます。 ■ ■・クリック数がリアルタイムで確認できる安心のシステム。 ■ ■・自由に選べる広告タグ。 ■ ■■ 広告掲載申し込みフォーム ■■■■■■■■■■■■■■ ■ ■ ご登録は↓こちらです ■ ■ http://click.ai-shitel.com/ ■ 尚、既にご契約頂いているサイトオーナー様、並びに現在交渉中・解約済・無関係な方へ配信されました場合は、ご迷惑をおかけし、大変申し訳ございません。御不要でしたら御手数ですが削除して頂きます様お願い致します。 ご質問等ございましたら 下記までご遠慮なくお問合せください。 ==================================================== 株式会社アイキュープランニング クリックシティー広告事業部 阿部 TEL:052-681-3362 HP： http://click.ai-shitel.com/ E-Mail: cli...@ai... ====================================================. |
|
From: Ken W. <ke...@ma...> - 2003-02-27 15:04:34
|
On Thursday, February 27, 2003, at 02:07 AM, Philippe M. Chiasson wrote: > > Or even potentially worst, if running in a C programm that embeds a > Perl > interpreter (read mod_perl), the value $^X will be that program (read > httpd), most certainly not always what one wants ;-( In fact, this had already occurred to me, for some reason. I put a comment about it in the M::B code. But so far it's not going to be a real problem, because most people don't build & install modules using an embedded perl. =) The only places the $perl value is used in M::B are to run external scripts (like '$perl Build.PL; $perl Build; $perl Build test' in the 'disttest' action) and to verify that the user isn't running actions with a different perl than they ran 'perl Build.PL' with. As I really try to keep any system() calls, including script-running, to an absolute minimum, M::B should probably work pretty well in embedded perls too. -Ken |
|
From: Nicholas C. <ni...@cc...> - 2003-02-27 10:30:42
|
On Thu, Feb 27, 2003 at 04:07:29PM +0800, Philippe M. Chiasson wrote:
> On Thu, 2003-02-27 at 06:18, Ken Williams wrote:
> >
> > On Wednesday, February 26, 2003, at 09:59 AM, Nicholas Clark wrote to
> > the Inline list:
> >
> > > As promised, er, a few months ago, here is a patch that makes Inline
> > > work reliably when there is more than one perl installed, and all
> > > *think*
> > > that they are (say) /usr/local/bin/perl
> >
> > You mean that all of them have /usr/local/bin/perl as
> > $Config{perlpath}, or that somehow symlinks or shebang paths are giving
> > them that impression?
The former. Although I have quite a few perl binaries installed, and know
how to hack Config.pm to (sort of) solve this, it's quite possible for
any "normal" user to get this merely by installing (say) 5.8.0 over
5.6.1, while having some scripts that are explicity still run with
/usr/local/bin/perl5.6.1
I'm not sure how perl copes with HP-UX, where (IIRC) argv[0] is set to the
path of a script, not the interpreter. (Helpful systems put the interpreter
in argv[0], seeing as the script's name is in argv[1] anyway)
> > > With this Inline will "believe" $^X in preference to $Config{perlpath}
> > > if $^X is an absolute path, so that Inline will get the same perl as is
> > > running the script, despite the sysadmin's best efforts to confuse
> > > things
> > > by installing more perl versions.
> >
> > I'm interested in getting this right for Module::Build too. This seems
> > like a reasonable approach to take. I think the big problem with $^X
> > is that it can sometimes be set to just "perl" or something in shebang
> > scripts, so checking for an absolute path seems like a good way to go.
> > Thanks.
>
> Or even potentially worst, if running in a C programm that embeds a Perl
> interpreter (read mod_perl), the value $^X will be that program (read
> httpd), most certainly not always what one wants ;-(
I'd not thought of that. I guess that one way is to also check if
$^X =~ m!perl[^/]*!
(or the directory separator equivalent to / as appropriate)
as I'm not sure if running $^X -v to see if it's "perl" is safe.
> Q: It is impossible to make anything foolproof because fools are so
> ingenious.
Hmm. Quite apt here :-) Or is that :-(
Nicholas Clark
|
|
From: Ken W. <ke...@ma...> - 2003-02-27 02:59:53
|
On Wednesday, February 26, 2003, at 07:52 PM, Randy W. Sims wrote:
>
> That wouldn't work as it's written. Just before the return there is a
> call to write_*_script() which delete()s the elements in the hash that
> it is able to write to the script file, so it needs to be grep{defined
> && length} to avoid warnings about the no longer existing elements.
Well, if you delete($spec{foo}), then @{$spec{foo}} returns an empty
list, not something with undef elements in it.
> I've attached a patch that fixes that and fixes a couple of
> inconsistencies in the way I was access $self->{config} (i.e. in most
> places I was accessing through the convenience variable $cf while in a
> couple of spots I spelled it out $self->{config}).
Good, $cf is nicer there. No possibility of misspelling 'congif'
either. =)
> In regards to warning users about undefined entries, I think it is
> valid for some options to be undefined, but I really don't know enough
> about typical usage across the various platforms to test the validity
> of options. I need to study modules like MakeMaker and others that use
> the compiler to see what they do, as well as studing some Makefile.PLs
> and the generated Makefiles to try to get a better grasp on how the
> compiler and linker are generally used.
My sense is that the cmd-line flags would be better left out than given
undef values. It doesn't seem to make much sense to do system('gcc',
'-foo', undef).
I'll apply your patch as-is, if for no other reason than the fact that
you can test things out, and I can't, so I ought to trust you more on
the code than myself. =)
-Ken
|
|
From: Randy W. S. <Ra...@Th...> - 2003-02-27 01:52:36
|
On 2/25/2003 10:24 PM, Ken Williams wrote:
>
> On Tuesday, February 25, 2003, at 06:56 PM, Randy W. Sims wrote:
>
>> On 2/24/2003 1:04 PM, Ken Williams wrote:
>>
>>> I was wondering about the check for boolean truth, which will turn
>>> argument lists like ('-foo', 0) into ('-foo'). Maybe it would be
>>> safer to just use grep {defined()}, or grep {defined() && length()},
>>> or something? Or are there some zeroes you're specifically trying to
>>> filter out?
>>> -Ken
>>
>>
>> Your right. Bad habbit. I know it's bad for me, but I can't stop...
>>
>> I can't think of anyway in which it might fail, but it should be changed.
>
>
> How about I just change it to
>
> return [
> $spec{cc}, '-c' ,
> @{$spec{includes}} ,
> @{$spec{cflags}} ,
> @{$spec{optimize}} ,
> @{$spec{defines}} ,
> @{$spec{perlinc}} ,
> "-Fo$spec{output}" ,
> $spec{source} ,
> ];
>
> ? Seems like we'll want to know if one of those values is undefined
> anyway, so we'll want to trigger the warning if warnings are turned on.
>
> -Ken
That wouldn't work as it's written. Just before the return there is a
call to write_*_script() which delete()s the elements in the hash that
it is able to write to the script file, so it needs to be grep{defined
&& length} to avoid warnings about the no longer existing elements.
I've attached a patch that fixes that and fixes a couple of
inconsistencies in the way I was access $self->{config} (i.e. in most
places I was accessing through the convenience variable $cf while in a
couple of spots I spelled it out $self->{config}).
In regards to warning users about undefined entries, I think it is valid
for some options to be undefined, but I really don't know enough about
typical usage across the various platforms to test the validity of
options. I need to study modules like MakeMaker and others that use the
compiler to see what they do, as well as studing some Makefile.PLs and
the generated Makefiles to try to get a better grasp on how the compiler
and linker are generally used.
Randy.
|
|
From: Ken W. <ke...@ma...> - 2003-02-26 22:18:46
|
On Wednesday, February 26, 2003, at 09:59 AM, Nicholas Clark wrote to
the Inline list:
> As promised, er, a few months ago, here is a patch that makes Inline
> work reliably when there is more than one perl installed, and all
> *think*
> that they are (say) /usr/local/bin/perl
You mean that all of them have /usr/local/bin/perl as
$Config{perlpath}, or that somehow symlinks or shebang paths are giving
them that impression?
> With this Inline will "believe" $^X in preference to $Config{perlpath}
> if $^X is an absolute path, so that Inline will get the same perl as is
> running the script, despite the sysadmin's best efforts to confuse
> things
> by installing more perl versions.
I'm interested in getting this right for Module::Build too. This seems
like a reasonable approach to take. I think the big problem with $^X
is that it can sometimes be set to just "perl" or something in shebang
scripts, so checking for an absolute path seems like a good way to go.
Thanks.
-Ken
|
|
From: Ken W. <ke...@ma...> - 2003-02-26 15:04:36
|
On Tuesday, February 25, 2003, at 06:53 PM, Randy W. Sims wrote:
> On 2/24/2003 12:56 PM, Ken Williams wrote:
>> That can wait until the future. To do this cleanly, I think we could
>> create a module like ExtUtils::C with classes like
>> ExtUtils::C::Compiler and ExtUtils::C::Linker that Module::Build
>> could just use transparently. Its purpose would be to compile and
>> link things that will be linked in with Perl modules (not a general
>> tool for arbitrary C code), using the same interface regardless of
>> platform.
>> We could use that module in other situations too, like in the testing
>> code for ExtUtils::ParseXS.
>> Probably the code you've written for Win32 and the code I wrote for
>> Unix would be a good start toward such a module. But given that the
>> module doesn't exist yet, we'll just have to wait. =)
>
> I've been thinking very seriously about writing those modules. My
> problem is the more I think about it the more ambitious the design
> becomes. I'm more inclined at the moment to design them as a framework
> not limited to 'C' and 'XS', so that Inline::* modules could make use
> of the framework if desired. Instead of ExtUtils::C::Linker, there
> would be something like:
>
> my $cc = new ExtUtils::Compiler(
> LANG => 'C',
> FLAGS => ...
> );
>
> $cc->compile( source => 'source.c', output => 'source.o' );
>
> In other words, it would operate like 'gcc' does, where it is a
> front-end driver for any number of different compilers.
Eek, dangerous road! ;-) When I've entertained writing this, it's only
by limiting the scope of the design that I can convince myself it's
worth doing, because I might have a reasonable chance of ever
finishing. =)
That said, probably all you'd need to do is define the *interfaces*,
implement the stuff we need for C compilation, and let other people
provide the code to support various languages.
By the way, one other author (Mitchell Charity) told me a while ago
about some work he was doing with ExtUtils::ParseXS in which he was
generating the C code in memory, then using TinyCC's libtcc to do an
all-in-memory compile and link, and claiming something like three
orders of magnitude difference in speed (faster, not slower ;-). I
probably wouldn't even understand the details if I knew them, but my
point is that tools like this could be really useful, because there are
people out there that can do cool stuff with them. So if you think you
could get something working, I'm completely supportive. =)
> I agree, in fact the first implementation actually used an aggregate
> relationship instead of inheritance. In fact there is still a relic of
> that design in there. In the constructor, you see:
>
> my $cc_driver = "Module::Build::Platform::Windows::$cf->{ccname}";
> unshift @ISA, $cc_driver;
>
> the next line used the be something like
> $self->{config}{cc_driver} = eval "new $cc_driver";
By the way, that can just be
$self->{config}{cc_driver} = $cc_driver->new();
> The problem was that it would have taken more code to implement mostly
> duplicating code already in M::B or storing a backref to the caller
> (which I generally prefer to avoid), and that really didn't seem to
> make sense within the context of M::B.
Okay. One way to avoid storing backreferences (for too long) is to use
weak references, but we probably don't want to get into that for M::B
either.
>
> In my notes, I put down the names of two of the files: 'Sample.pm' &
> 'MANIFEST'. There may be others; I admit that I mostly ignored the
> errors at the time because I was focusing on the compiling/linking
> tests and I didn't want to get sidetracked. I'll take a closer look at
> this.
Does anything change if you add an explicit close() in
version_from_file() ? I think that's the only place Sample.pm would be
opened.
For the MANIFEST, all that code is buried in ExtUtils::Manifest, so
it'll be harder to fix, probably.
> This is something else I wanted to revisit. If I'm not mistaken this
> may actually be a Perl bug that was in 5.6.1, but has since been
> fixed. At least I think I remember some problem being fixed in the
> system() call.
Oh yuck. =( Well, let me know if you find anything, but I hope you
don't!
> I guess it could be argued either way: subclassing or passing
> arguments to M::B's constructor. If subclassing, users need to know
> that on some platforms that there is a prelink operation, and that it
> generally involves a call ExtUtils::Mksymlists. They will have to
> reference that documentation to see what arguments they need to pass.
> If it were just parameters passed to M::B's constructor, It would
> arguably simplify the interface and documentation, at least from the
> users perspective. However, design-wise it shifts responsiblities in
> the wrong direction; the reason there is a seperate module for
> Mksymlists in the first place is to move that responsiblity out of the
> package used for building modules.
Indeed.
> The way I wrote the prelink_c() routine should allow you easily go in
> either direction as you prefer.
Okay, thanks.
-Ken
|
|
From: Ken W. <ke...@ma...> - 2003-02-26 03:24:21
|
On Tuesday, February 25, 2003, at 06:56 PM, Randy W. Sims wrote:
> On 2/24/2003 1:04 PM, Ken Williams wrote:
>> Hi Randy,
>> I noticed this line in the format_compiler_cmd() code from your patch:
>> return [ grep {defined && $_} (
>> $spec{cc}, '-c' ,
>> @{$spec{includes}} ,
>> @{$spec{cflags}} ,
>> @{$spec{optimize}} ,
>> @{$spec{defines}} ,
>> @{$spec{perlinc}} ,
>> "-Fo$spec{output}" ,
>> $spec{source} ,
>> ) ];
>> I was wondering about the check for boolean truth, which will turn
>> argument lists like ('-foo', 0) into ('-foo'). Maybe it would be
>> safer to just use grep {defined()}, or grep {defined() && length()},
>> or something? Or are there some zeroes you're specifically trying to
>> filter out?
>> -Ken
>
> Your right. Bad habbit. I know it's bad for me, but I can't stop...
>
> I can't think of anyway in which it might fail, but it should be
> changed.
How about I just change it to
return [
$spec{cc}, '-c' ,
@{$spec{includes}} ,
@{$spec{cflags}} ,
@{$spec{optimize}} ,
@{$spec{defines}} ,
@{$spec{perlinc}} ,
"-Fo$spec{output}" ,
$spec{source} ,
];
? Seems like we'll want to know if one of those values is undefined
anyway, so we'll want to trigger the warning if warnings are turned on.
-Ken
|
|
From: Randy W. S. <Ra...@Th...> - 2003-02-26 00:56:41
|
On 2/24/2003 1:04 PM, Ken Williams wrote:
> Hi Randy,
>
> I noticed this line in the format_compiler_cmd() code from your patch:
>
> return [ grep {defined && $_} (
> $spec{cc}, '-c' ,
> @{$spec{includes}} ,
> @{$spec{cflags}} ,
> @{$spec{optimize}} ,
> @{$spec{defines}} ,
> @{$spec{perlinc}} ,
> "-Fo$spec{output}" ,
> $spec{source} ,
> ) ];
>
> I was wondering about the check for boolean truth, which will turn
> argument lists like ('-foo', 0) into ('-foo'). Maybe it would be safer
> to just use grep {defined()}, or grep {defined() && length()}, or
> something? Or are there some zeroes you're specifically trying to
> filter out?
>
> -Ken
Your right. Bad habbit. I know it's bad for me, but I can't stop...
I can't think of anyway in which it might fail, but it should be changed.
Randy.
|
|
From: Randy W. S. <Ra...@Th...> - 2003-02-26 00:53:39
|
On 2/24/2003 12:56 PM, Ken Williams wrote:
> That can wait until the future. To do this cleanly, I think we could
> create a module like ExtUtils::C with classes like ExtUtils::C::Compiler
> and ExtUtils::C::Linker that Module::Build could just use
> transparently. Its purpose would be to compile and link things that
> will be linked in with Perl modules (not a general tool for arbitrary C
> code), using the same interface regardless of platform.
>
> We could use that module in other situations too, like in the testing
> code for ExtUtils::ParseXS.
>
> Probably the code you've written for Win32 and the code I wrote for Unix
> would be a good start toward such a module. But given that the module
> doesn't exist yet, we'll just have to wait. =)
I've been thinking very seriously about writing those modules. My
problem is the more I think about it the more ambitious the design
becomes. I'm more inclined at the moment to design them as a framework
not limited to 'C' and 'XS', so that Inline::* modules could make use of
the framework if desired. Instead of ExtUtils::C::Linker, there would be
something like:
my $cc = new ExtUtils::Compiler(
LANG => 'C',
FLAGS => ...
);
$cc->compile( source => 'source.c', output => 'source.o' );
In other words, it would operate like 'gcc' does, where it is a
front-end driver for any number of different compilers.
> Also, I think a "uses-a" or "has-a" relationship to the compiler/linker
> would make more sense than the "is-a" relationship that's now in the
> M::B::P::Windows.pm code, but I understand that this was probably an
> easier way to get things written.
I agree, in fact the first implementation actually used an aggregate
relationship instead of inheritance. In fact there is still a relic of
that design in there. In the constructor, you see:
my $cc_driver = "Module::Build::Platform::Windows::$cf->{ccname}";
unshift @ISA, $cc_driver;
the next line used the be something like
$self->{config}{cc_driver} = eval "new $cc_driver";
The problem was that it would have taken more code to implement mostly
duplicating code already in M::B or storing a backref to the caller
(which I generally prefer to avoid), and that really didn't seem to make
sense within the context of M::B.
>> Outstanding issues:
>>
>> The 'runthrough.t' test sometimes fails in random places at random
>> times. This is true with or without the modifications I've made.
>> Sometimes 2 tests fail, sometimes 5, sometimes ??, most of the time
>> none--It's completly unpredictable. It happens after ./build
>> (real)clean as often as it happens after back to back runs of ./build
>> test. I have not yet had a chance to look into it, but I'm pretty
>> certain of the cause. Windows seems to be extremely sensitive about
>> file operations. Sometimes a file gets locked (not always the same one
>> in this case), and it can no longer be accessed. This usually means
>> that a file handle was not explicitly closed or a tied file was not
>> untied, etc.
>
>
> Yes, there were a couple of places I had to deal with this problem for
> the Win32 folks. Are you using the latest CVS version of M::B, or the
> CPAN version? The CVS version fixed a few things, but it's likely there
> are more instances of this problem lurking. Is there any way to get an
> error message to tell you what file is in contention?
In my notes, I put down the names of two of the files: 'Sample.pm' &
'MANIFEST'. There may be others; I admit that I mostly ignored the
errors at the time because I was focusing on the compiling/linking tests
and I didn't want to get sidetracked. I'll take a closer look at this.
>> Another place I ran into problems with locked files is with the
>> 'system()' call. My first stab at getting M::B to work was basically a
>> copy, paste, and edit of the 'compile_c()' and 'link_c()' routines in
>> Base.pm, with branches all over the place to handle differences in
>> compiler syntax. When passing a LIST to system(), It would compile,
>> but the next call to system() to invoke the linker would fail with an
>> 'access denied' error. If I joined the list into a single string it
>> would work (don't ask how long it took me to track that down to the
>> system() call).
>
>
> Ack - I'm really trying to avoid system(STRING) calls, because I really
> don't want shell metachars involved anywhere. Differences in shell
> behavior can open up a whole new can of worms I'm trying to avoid.
>
>
>> At some point I decided to revisit the issue to figure out exactly
>> what was happening, unfortunatelly changing back to the LIST form now
>> works as expected--It has never failed with that error again. This was
>> after I restructured the code, so I can only assume... bah, I won't
>> assume anything.....
>
>
> We'll just keep our eye on it, I guess.
This is something else I wanted to revisit. If I'm not mistaken this may
actually be a Perl bug that was in 5.6.1, but has since been fixed. At
least I think I remember some problem being fixed in the system() call.
>> Most of the time it is invoked with just the name of the module being
>> built, but sometimes it's neccessary to pass in lists of
>> functions/variables. I thought it would be best to leave it to you as
>> to how the user will pass the information through. As it is, it
>> should work for most modules, and a small change to 'sub prelink()'
>> telling it where to get the user supplied options will allow it to
>> work those modules that need that extra functionality.
>>
>
> Okay, so people could override prelink_c() in their own subclasses?
I guess it could be argued either way: subclassing or passing arguments
to M::B's constructor. If subclassing, users need to know that on some
platforms that there is a prelink operation, and that it generally
involves a call ExtUtils::Mksymlists. They will have to reference that
documentation to see what arguments they need to pass. If it were just
parameters passed to M::B's constructor, It would arguably simplify the
interface and documentation, at least from the users perspective.
However, design-wise it shifts responsiblities in the wrong direction;
the reason there is a seperate module for Mksymlists in the first place
is to move that responsiblity out of the package used for building modules.
The way I wrote the prelink_c() routine should allow you easily go in
either direction as you prefer.
Randy.
|
|
From: Ken W. <ke...@ma...> - 2003-02-25 17:48:40
|
On Tuesday, February 25, 2003, at 04:47 AM, Randy J. Ray wrote: > I've been testing some of my modules against 5.00503 lately, and since > I've been looking at porting to Module::Build, I just tried to install > it under that version. It uses some things that aren't valid in > 5.00503, such as: > > $self->$method; # Needs explicit () between $method and ; > > open($fh, ...) # Where $fh is undef. This is why I was testing > 5.00503 > > You may not want to keep compatibility that far back (I wouldn't, but > I've had requests for help from more than one person). If not, you > might consider setting a Perl baseline with "require 5.6.0" or > something. > > Randy > -- > """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" > """""""" > Randy J. Ray Campbell, CA http://www.rjray.org > rj...@bl... > > Silicon Valley Scale Modelers: http://www.svsm.org Hi Randy, To preserve my sanity, and because I wanted to use some 5.006 features, I did explicitly set a prerequisite of 5.6 (see the "perl => '5.6.0'," in the Build.PL file). I could be convinced to backport it, or rather to accept a backporting patch, but I'd definitely need to keep things like qr{}, so I couldn't really go back any further than 5.005_03. That said, I can certainly change the $self->$method thing, I'm a little surprised I left out the parens there. The undef $fh thing is a little more of a pain, but if that's the only obstacle left I suppose I could change it too. I suppose I should also put a BEGIN{require 5.006} in too - I'm trying to remember why I didn't do that, and I can't remember, so I guess I'll do it. ;-) Now that I think of it, my original goal was to make M::B work with just the *modules* that are in the 5.6.0 core (which is still the case for the "required" modules, but some non-core modules are "recommended"), not necessarily to force people to have 5.6 as a prereq. Either way, I'm interested in knowing how far away 5.005_03 support would be. Thanks for checking into this. -Ken |
|
From: Ken W. <ke...@ma...> - 2003-02-25 15:08:54
|
On Monday, February 24, 2003, at 07:23 PM, Brian Ingerson wrote: > Heh. Touche! > > Well I actually did consider a regression test patch, but I noticed you > didn't have any tests for './Build install' so I blew it off. Now that there's a 'destdir' parameter to 'install', I should be able to write a test fairly easily, actually. I'll get on it for the next release. This is pretty important, I think, so thanks for reminding me. -Ken |
|
From: Brian I. <in...@tt...> - 2003-02-25 01:24:11
|
On 24/02/03 14:48 -0600, Ken Williams wrote: > > On Monday, February 24, 2003, at 02:22 PM, Brian Ingerson wrote: > > > > (Show me a failing test, and I'll show you a patch! ;) > > Heh - show me a test for only.pm in Module::Build's regression tests, > and that would help me never show you a failing test. =) Heh. Touche! Well I actually did consider a regression test patch, but I noticed you didn't have any tests for './Build install' so I blew it off. > Anyway, patches are no good for already-released software - there will > still be buggy combinations out there if such bugs are found by others. > > For instance, bug: with version 0.25, if only.pm can't find a 'version' > in get_meta(), it will die regardless of whether the user supplied a > 'version' argument. ouch. good catch. > It's also possible for the 'distribution_name' key to be null in your > meta-file, because it's never checked for success. Yeah, I know. That field is only for documentation at this point, so I was silently forgiving. > I'm not trying to pick on your work, I'm just saying that it's hard to > write bug-free (or bug-rare) software without a few releases of it, and > that's why I'm saying it's "volatile" at this point. Later it will > become "mature", no doubt. Pick away! I truly appreciate other people's input and opinions. > Actually, were you objecting to my use of the word "volatile", or that > I required version 0.25 of only? Not objecting. Just wondering. Thanks for the clarification. And I think that requiring 0.25 is a good thing. Cheers, Brian |
|
From: Ken W. <ke...@ma...> - 2003-02-24 20:48:15
|
On Monday, February 24, 2003, at 02:22 PM, Brian Ingerson wrote: > > (Show me a failing test, and I'll show you a patch! ;) Heh - show me a test for only.pm in Module::Build's regression tests, and that would help me never show you a failing test. =) Anyway, patches are no good for already-released software - there will still be buggy combinations out there if such bugs are found by others. For instance, bug: with version 0.25, if only.pm can't find a 'version' in get_meta(), it will die regardless of whether the user supplied a 'version' argument. It's also possible for the 'distribution_name' key to be null in your meta-file, because it's never checked for success. I'm not trying to pick on your work, I'm just saying that it's hard to write bug-free (or bug-rare) software without a few releases of it, and that's why I'm saying it's "volatile" at this point. Later it will become "mature", no doubt. Actually, were you objecting to my use of the word "volatile", or that I required version 0.25 of only? -Ken |
|
From: Brian I. <in...@tt...> - 2003-02-24 20:22:53
|
On 24/02/03 13:04 -0600, Ken Williams wrote:
>
> On Sunday, February 23, 2003, at 08:20 PM, Brian Ingerson wrote:
>
> > On 19/02/03 20:43 -0600, Ken Williams wrote:
> >> Applied!
> >>
> >> I think the fact that $only::config::versionlib,
> >> $only::config::versionarch, and @ARGV need to be manipulated
> >> dynamically means that only.pm needs a little interface work, though -
> >> do you plan on adding a programmatic interface that could just accept
> >> this stuff as arguments?
> >
> > And now for that patch I promised. Sorry I took so long, but you
> > challenged me to go back and refactor only.pm, which I did a whole
> > bunch
> > of. I think you'll find the new patch to be much cleaner :)
>
> Here's how I'm applying it:
>
> sub ACTION_versioninstall {
> my ($self) = @_;
>
> die "You must have only.pm 0.25 or greater installed for this
> operation: $@\n"
> unless eval { require only; 'only'->VERSION(0.25); 1 };
>
> $self->depends_on('build');
>
> my %onlyargs = map {exists($self->{args}{$_}) ? ($_ =>
> $self->{args}{$_}) : ()}
> qw(version versionlib);
> only::install::install(%onlyargs);
> }
>
> There might be other things in the $self->{args} hash that you don't
> want to pass to only::install::install(), so I had to check for
> specific keys.
ok, but...
I had it that way on purpose because only::install::install ignores
unknown parameters. That way it could be forward compatible with new
only::install args.
but, that's fine, because I'd still want to patch the M::B docs for the
new args.
Thanks for applying.
> I've also added a caution in the Changes file that the interface still
> seems volatile.
How so?
(Show me a failing test, and I'll show you a patch! ;)
> If I had more time I'd offer some feedback on the OO interface, but
> unfortunately I'm up against a bit of a time wall here. =(
Yeah well, no problem. We all have lots to do!
I put the OO interface into the latest release: only-0.25. I also
refactored the internals to use the same OO interface. I'm pretty happy
with how it all turned out.
But I'd love to hear your comments someday. :)
Cheers, Brian
|
|
From: Ken W. <ke...@ma...> - 2003-02-24 19:15:36
|
Hi,
The uploaded file
Module-Build-0.16.tar.gz
has entered CPAN as
file: $CPAN/authors/id/K/KW/KWILLIAMS/Module-Build-0.16.tar.gz
size: 56639 bytes
md5: 070af84a3c5cfc671210a687a5aa350a
Changes since 0.15:
0.16 Mon Feb 24 13:06:47 CST 2003
- All three C compilers that perl supports on Windows environments
(MSVC, BCC, and GCC) are now supported by Module::Build. We now
reportedly pass all tests on Windows. [Randy W. Sims]
- The test t/xs.t, which tests building of XS modules, will be
skipped if no C compiler is found. [suggested by Randy W. Sims]
- The "install" action accepts new "destdir" [motivated by Michael
Schwern and Chip Salzenberg] and "uninst" parameters [by Dave
Rolsky]. The former prepends an arbitrary directory to all
installation paths (useful for package management), and the latter
will tell ExtUtils::Install to remove any differing files that are
"shadowing" the stuff you're installing from a different location,
just like MakeMaker's "make install UNINST=1" command will do.
- Made changes to the generated Makefile in Module::Build::Compat
that much better support Windows platforms [after suggestions by
James Freeman]
- Added experimental support for creating distribution SIGNATURE
files via Module::Signature. [Dave Rolsky]
- Added experimental support for installing via the "only.pm" module,
which allows loading specific versions of modules. Since this
module is so new, the interface may still be changing. [Brian
Ingerson]
- Added support for installing executable scripts, via the 'scripts'
parameter to new(), and the scripts() accessor method.
- Fix an infinite loop that occurred when doing 'perl Build.PL
config="foo=bar"'
- Fix up the formatting of the error message the user gets when
prereqs aren't satisfied.
-Ken
|
|
From: Ken W. <ke...@ma...> - 2003-02-24 19:04:53
|
On Sunday, February 23, 2003, at 08:20 PM, Brian Ingerson wrote:
> On 19/02/03 20:43 -0600, Ken Williams wrote:
>> Applied!
>>
>> I think the fact that $only::config::versionlib,
>> $only::config::versionarch, and @ARGV need to be manipulated
>> dynamically means that only.pm needs a little interface work, though -
>> do you plan on adding a programmatic interface that could just accept
>> this stuff as arguments?
>
> And now for that patch I promised. Sorry I took so long, but you
> challenged me to go back and refactor only.pm, which I did a whole
> bunch
> of. I think you'll find the new patch to be much cleaner :)
Here's how I'm applying it:
sub ACTION_versioninstall {
my ($self) = @_;
die "You must have only.pm 0.25 or greater installed for this
operation: $@\n"
unless eval { require only; 'only'->VERSION(0.25); 1 };
$self->depends_on('build');
my %onlyargs = map {exists($self->{args}{$_}) ? ($_ =>
$self->{args}{$_}) : ()}
qw(version versionlib);
only::install::install(%onlyargs);
}
There might be other things in the $self->{args} hash that you don't
want to pass to only::install::install(), so I had to check for
specific keys.
I've also added a caution in the Changes file that the interface still
seems volatile.
If I had more time I'd offer some feedback on the OO interface, but
unfortunately I'm up against a bit of a time wall here. =(
-Ken
|
|
From: Ken W. <ke...@ma...> - 2003-02-24 18:04:58
|
Hi Randy,
I noticed this line in the format_compiler_cmd() code from your patch:
return [ grep {defined && $_} (
$spec{cc}, '-c' ,
@{$spec{includes}} ,
@{$spec{cflags}} ,
@{$spec{optimize}} ,
@{$spec{defines}} ,
@{$spec{perlinc}} ,
"-Fo$spec{output}" ,
$spec{source} ,
) ];
I was wondering about the check for boolean truth, which will turn
argument lists like ('-foo', 0) into ('-foo'). Maybe it would be safer
to just use grep {defined()}, or grep {defined() && length()}, or
something? Or are there some zeroes you're specifically trying to
filter out?
-Ken
|
7 messages has been excluded from this view by a project administrator.
![http://www.ye2000.com/build/images/pop/mailbuild01.gif"](http://www.ye2000.com/build/images/pop/mailbuild01.gif"){kind=link}
![http://www.kingland.net.cn/zhiye/znrd/znruodian_zhbx_01.gif"](http://www.kingland.net.cn/zhiye/znrd/znruodian_zhbx_01.gif"){kind=link}
![http://www.kingland.net.cn/zhiye/znrd/znruodian_aqff_06.gif"](http://www.kingland.net.cn/zhiye/znrd/znruodian_aqff_06.gif"){kind=link}
![http://www.kingland.net.cn/zhiye/znrd/znruodian_zhbx_05.gif"](http://www.kingland.net.cn/zhiye/znrd/znruodian_zhbx_05.gif"){kind=link}
![http://www.kingland.net.cn/zhiye/znrd/znruodian_zhbx_02.gif"](http://www.kingland.net.cn/zhiye/znrd/znruodian_zhbx_02.gif"){kind=link}
![http://www.kingland.net.cn/zhiye/znrd/znruodian_zhbx_03.gif"](http://www.kingland.net.cn/zhiye/znrd/znruodian_zhbx_03.gif"){kind=link}
![http://www.kingland.net.cn/zhiye/znrd/znruodian_zhbx_04.gif"](http://www.kingland.net.cn/zhiye/znrd/znruodian_zhbx_04.gif"){kind=link}