设置Solidworks系统属性
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。工程图的创建与技巧(1)
&&你当前的位置：&&&&
&&&&&&&&&&&&&工程图的创建与技巧(1)
&&&一、 基本情况
&&& 二维工程图，是机械设计的最后一步，出工程图是必须完成的，因为工程图是设计意图实现（零部件制造）中，设计信息的最主要携带和表达者。Inventor已经提供了创建二维工程图（零件图、装配图）的功能，而且可以做到二维与三维相关联更新…
&&& 据笔者的了解，目前的三维软件都不能很完美地出工程图。从三维模型开始，按照平行正投影规则得到的结果图线，这是软件能把握和重现的规则。可是这些规则与实际工程图要求规则并不是完全一致的。原因很简单：工程图中有大量的人为规定。例如：简化画法、筋不剖、过渡线的规定… 这些规则不要说不同国家的设计标准，就是在我国，不同行业、甚至同行业的不同设计部门，也有区别。这种纷繁复杂的、各国习惯也不一致的、与三维模型的真实投影结果不完全相同的规定，要想利用一个软件的自身功能完全解决，实在是一件相当困难的事情。
&&& 但是，从三维的零件甚至装配模型开始，几乎自动地、正确地、可关联更新地得到需要的工程图，则是三维CAD软件才能做到的事情，这可望解决80%以上的工程图绘制自动化的问题。这里将以最新的Inventor R10版本为环境，讨论工程图相关的问题。对于较老的版本，其中绝大多数方法和技巧都是可用的。
&&& Inventor在解决上述问题上，作了大量的努力，目前的功能在同类软件中应当算是比较好的一个了,参见图1，其中列出的主要功能。
图1 主要功能
二、 体验工程图视图创建的过程
&&& 这里我们以现有的三维零件模型“1313-螺母.IPT”进行介绍。
&&& 2.1 零件视图创建
&&& ☆ 在菜单中“文件(F)”-〉“新建(N)”,在模板选定界面（参见图2）的Metric选项卡中，双击“GB.IDW”，进入Inventor提供的中国标准的工程图环境；
图2 开始新图的界面局部
&&& ☆ 在“工程视图面板”工具面板上启用“基础视图”功能,在接着弹出的“工程图视图”界面中，点击“路径”按钮，然后在“打开”界面中“1313-螺母.IPT。最后按下“打开(O)”按钮。整个过程参见图3。
图3 找到要生成工程图的零件
&&& ☆ Inventor将自动回到“工程图视图”界面，在“方向(O)”中选定第一个视图的表达方向(右视图)；在“比例(S)”栏目中点击右侧黑三角，拉下比例列表，从中选定合适的比例(1:1)；在“样式(T)”栏目中设置成“消隐”… 结果见图4；
图4 确定第一视图的各项参数
&&& ☆ 这时Inventor将动态显示未来的结果。拖动光标，确定这个视图在图纸上的位置，在合适的条件下按下拾取键。结果如图5。
图5 第一个视图结果
&&& ☆ 在这个视图中，本想将螺纹孔放在上边，而现在是在左边，完成这个要求可以使用旋转视图方向的功能。方法是，先将光标放在这个视图的区域中，Inventor将感应到它，并用红色点线方框圈出；这时单击右键，在接着弹出的菜单中选定“旋转(R)”功能。
&&& 接着将弹出“旋转视图”界面，在“依据”栏目选定使用“角度”方式，并输入视图转过的角度90°和转动放方向。参见图6的过程。
图6 旋转视图方向的操作
&&& ☆ 从工程图总体看来，图形显得很小，可见图纸太大了，可以调整图纸大小。先将光标放在视图上，当Inventor感应出移动标记后，拖动到图纸的中心位置；之后在浏览器中选定“图纸：1”，在右键菜单中“编辑图纸(E)…”，在“格式”栏目拉出“大小(S)”列表，将工程图规格改成A4幅面（参见图7），以适应这个零件。
图7 调整图纸大小
&&& 2.2 零件剖视图创建
&&& ☆ 现在创建零件的全剖视图。在“工程图视图面板”工具面板上启用“剖视图”功能。先将光标放在主视图上悬停，会出现视图的红色点线边框。单击选定（图8左 1）；再把光标放在螺母圆心上，等待Inventor感应到中心点（图8左2），会出现绿色圆心点；向上移拉动光标到期望的剖切符号位置（图8左3），拾取，这是剖切线的第一个点；竖直向下移动光标，确定剖切线的第二个点（图8左4），拾取；
图8 剖面图创建过程
&&& ☆ 在右键菜单中“继续”，将弹出相关的“剖视图”对话框（参见图9左），在其中设置好相关的参数（例如剖面符号“A”、比例“1”…），拖动剖视图预览到合适的位置，按下拾取键确定，创建剖视图，如图9右侧。
图9 创建剖面图最后两步
&&& 2.3 零件图辅助线
&&& ☆ 自动添加中心线
&&& 选定视图，在右键菜单中启用“自动中心线…”功能，将弹出图10的界面，在其中设置需要的参数和状态，“确定”之后Inventor将按设置的条件，自动创建可能的中心线。建完成的中心线，可以在选定时看到几个亮绿色的点，拖动这些点可以调整中心线的长短。
图10 自动中心线参数设置
&&& ☆ 手工添加中心线
&&& 如果Inventor没能自动创建我们所需要的中心线，工程图要求又必须有这条中心线，可以手动添加。例如启用“工程图标注”工具面板中的“对分中心线”（就是“对称线”的意思）功能，参见图11，再先后选定视图中两个对称的图线，即可创建完成的中心线。
图11 中心线功能
&&& 在Inventor的中心线上，可以在选定时看到几个亮绿色的点，拖动这些点可以调整中心线的长短。结果参见001.IDW。
三、 体验零件图尺寸标注
&&& 尺寸标注，实在是考验工程师绘制工程图和设计水平的主要指标之一。也就是说，即使是人，在设计能力不太好的条件下，尺寸标注也难以做到完美、正确。而 Inventor在做这件事的时候，却有可能比不太好的工程师表现得更好。当然，在工程图尺寸标注的创建上，最后还是要*工程师的能力和后期的润色、修饰和增删。
&&& 不过，在Inventor中，一旦建立了尺寸标注，就能与三维模型建立起自动的关联关系，在模型修改后，相关尺寸将自动修改。这是Inventor十分优秀的工程图处理性能，也是在设计支持的功能中，十分重要而又有实用价值的。
&&& Inventor目前可提供两类标注方法：自动的、手动的，而且都能与图线双向关联。
&&& 3.1 自动尺寸标注
&&& 这是自动引用某视图方向可用的、全部模型上的约束尺寸，包括草图尺寸和特征尺寸，并将其转变成工程图的标注尺寸。操作如下：
&&& ☆ 在“工程图标注”面板上启用“检索尺寸”，按界面中的要求选定要处理的视图，或者选定视图，在右键菜单中“检索尺寸(R)…”；
&&& ☆ 之后会在浏览器中将展开这个视图相关的零件结构特征，并在界面中提示“选择特征”。在浏览器中选定、或者在视图中选定特征，如果有可以借用的尺寸，将会显示出来。例如图中选定了“打孔1”特征（参见图12）；
图12 借用模型尺寸
&&& ☆ 按下“选择尺寸”按钮，在视图上选定准备留下来的模型尺寸，“应用”。
&&& 接着可以继续这样操作，完成其它的模型尺寸饮用，最后以“确定”结束。这样的尺寸标注多数是不能直接使用的，需要进行位置调整和修饰。调整方法是：将光标放在尺寸文字附近，当Inventor感应反馈出四个小箭头的标记时，按下拾取键，拖动到满意的位置。也可以在工程图中隐藏不需要的模型尺寸，操作方法是：选定尺寸，再右键菜单中“删除(D)”。说“删除”，其实这个尺寸还存在，仅是藏起来了。
&&& 对于工程图上的来自模型的尺寸，可以修改它的值，并逆向关联修改相关的模型（如果在安装Inventor中确定了这种功能）。但是笔者认为这样的操作永远不应当进行。因为仅仅在工程图上修改，还不能确定对整个设计的影响到底怎样。
&&& 3.2 标注孔
&&& 对于“打孔”特征，Inventor有专门的标注工具（参见图13）。启用“孔/螺纹孔标注”，可以在这个特征的相关投影图线上标注。但是如果不是“孔特征”做的结构，即便我们认为应当是“孔”，而且确实很像（例如用圆截面拉伸切割成的孔），Inventor也不能用这个功能标注，这就是规则的差异。
图13孔特征标注功能和实例
&&& 如果读者在标注孔的时候不能实现图13的效果，可以试着改变尺寸参数。选定一个孔标注，在右键菜单中“编辑尺寸样式(S)…”,在如图14的界面中,切换到“注释和指引线”选项卡，调整“指引线样式”下面的文字位置呈水平即可。
图14 修改指引线文字位置参数
&&& 3.3 手工尺寸标注
&&& Inventor的尺寸标注是一种“智能”的工具，随着所选定的图线的不同，会自动切换标注类型；但是，具体的细节，还是需要操作者确认。
&&& 参见图15，选定外径的投影圆弧（图中箭头指定的线），想标直径尺寸30，拉出尺寸，可见Inventor自动加上R前缀，因为被标注的是一段弧；这时，可在右键菜单中讲“尺寸类型(T)”改成“直径(D)”。
图15 手工标注实例
&&& 特殊地，Inventor的相关规则是，所有不是圆面的投影线，就不是圆柱相关，因此就没有直径标记。参见“003.IDW”，其中的尺寸30就是对着圆柱结构的两条投影直线标注的，Inventor没有加上直径标记。这时，需要我们自己进行修饰。想在前面加上“ф”，具体过程是：先选定这个尺寸，在右键菜单中“文本(T)…”，在接着弹出的对话框中，将光标放在“&&&&”号的左边，再在符号栏目中选定“ф”（参见图16），之后确认。
图16 添加前缀符号
&&& 3.4 粗糙度和形位公差符号标注
&&& 启用工程图标注面板上的“形位公差”和“表面粗糙度”功能，按提示进行操作即可。结果参见004.IDW和图17。
图17 粗糙度和形位公差
&&& 3.5 其它注释
&&& 启用工程图标注面板上的“文字”功能，按提示进行操作，写入技术要求。参见005.IDW。
&&& 3.6 零件图线宽度调整
&&& 在Inventor中，图线的宽度、颜色、线形等特征，是在“层”中设置和控制的，默认状态下，图线在那个层中，就具有了这个层设置的特征；也可以交互操作，设置选定图线的相关特征。而默认的轮廓线宽是0.5mm，而GB的一般习惯是0.7mm，设置修改的方法是，在菜单中“格式(O)”-〉“样式编辑器 (E)…”，之后“样式和标准编辑器”界面中展开“图层”列表，选定并修改其中的“可见(ISO)”层的线宽设置，结果将立即在工程图中表现出来。结果参见006.IDW。
&&& 注意：这种修改的效果，仅是控制当前图样中的线条，不是Inventor全局的控制结果。对于大多数层的参数设置，Inventor默认值是符合GB规则的。
四、 零件图小结
&&& 看来，工程图的标注，仍然是创建过程中的“瓶颈”。这种连人也不能轻易搞好的事情，软件自动实现当然更有困难。工程图的标注总是在考验着工程师的设计能力。作为支持软件的Inventor，已经提供了相当充分的支持功能。
&&& 4.1 关于双向关联
&&& 在Inventor中工程图处理结果，是“二、三维数据双向关联更新”的模式。也就是说，在相关工程图创建完成之后，三维零件模型的修改，会引发工程图的自动更新；而对于工程图尺寸的修改也会逆向造成三维模型的关联修改。这种逆向修改有两个需要注意的事情：
&&& 1） 不要轻易这样做，因为这样的结果可能造成在装配中相关零部件的问题…
&&& 2） 只有直接引用自模型的尺寸才可能实现这个效果（参见图18坐），交互操作所标注的尺寸，没有这种操作可能（参见图18右）。
图18 尺寸的编辑更新
&&& 4.2 关于截交与相贯
&&& 至于从三维模型投射得到相关的二维工程图，因为Inventor的算法中完全包含了平行正投影的机制，比较完整地包含了机械图表达中人为制定的规则，所以，一个并不熟悉机械制图线绘制基本技术和规则的人，如果是在Inventor的支持下，一样能做出漂亮的结果，参见图19和000.IDW。
图19 复杂投影结果
&&& 这就是CAD技术在这个局部大幅度地替代了人需要进行的、繁重的绘图过程，进而提高质量和效率的典型表现。这也是三维CAD软件给工程师们带来的新的设计支持机制，甚至因此，我们的大学机械制图教学，可能会有一些调整…
&&& 4.3 以三维模型为基础的工程图
&&& 从机械工程图的原理上说，是以三维模型为基础的。在CAD软件尚未提供相关支持的时代，也是如此。与现在不同的仅在于“谁”来进行三维模型与工程图的转换、关联。
&&& 显然，传统的方法是软件操作者进行。模型只存在于人的大脑中，转换过程是人利用大学的机械制图教育确定的规则，图线是人利软件描绘而成。因为模型构造数据不在软件的数据库中，关联改变也就只能通过人的头脑进行处理，然后修改相关图线。而用三维模型投射得到相关的二维工程图的过程，则是软件管理模型数据、软件在使用我们在大学机械制图教育确定的规则、软件在产生我们需要的相当复杂的处理结果。
&&& 因此，结果虽然类似，这个“谁”的角色转变，成为主要的变化，带来新的效能。
&&& 从这个意义上说，我们宁可先作三维模型，然后据此创建二维工程图；也不会去直接绘制二维工程图。因为这可能更快捷。例如一个简单的方块：
&&& 直接绘制工程图，我们需要绘制三个矩形、关心三个视图的“长对正、高平齐、宽相等”、关心比例、关心几个视图在图纸上的位置… 在原始设计改变后，所有的变化都要一一处理。从三维模型开始，我们需要绘制一个矩形草图，做拉伸特征；之后的工程图创建将是极其简单的事情，与机械图基本概念完全一致。而且不必关心视图之间关系、比例、位置等问题，也不必关心原始设计改变之后的关联更新。因为这些规则Inventor知道，并能够自动处理。可见，即便是在如此简单的工程图，从三维模型开始，也会简化过程、提高效率，而对于复杂的工程图，这种效果将更为明显。
&&& 4.4 Inventor工程图数据结构的特点
&&& 值得注意的是，Inventor的工程图与AutoCAD的同类结果，在数据架构上有着本质不同。
&&& AutoCAD下的工程图，在创建时绝大多数是独立的一根根图线，相互没有直接的关联；创建后每一根图线都可能单独修改，与其他图线也没有关联关系…
&&& 而Inventor的工程图图线，并非单独的图线，而是三维模型在指定方向上、向指定平面、按平行正投影（或者其他）规则、根据机械制图的规定（轮廓线、中心线、隐藏线等处理规定）得到的“投射结果”，所以是自动关联的，所以是不可能直接修改结果图线的形状和位置的。这才是真正符合机械设计中工程图的原理和实际结果要求的。
&&& 总之，Inventor中这种以三维模型为基础的工程图创建功能和全过程，完全符合经典的设计成和规则，能大大减轻工程师的劳动量，保证质量，提高效率。
共&2&页：【】
版权所有&&&&民众工作室.制作后使用快捷导航没有帐号？
只需一步，快速开始
扫一扫，访问微社区
只需一步，快速开始
扫一扫，访问微社区
&&&&&系统[系统通知] 5天前系统[系统通知] 19天前系统[系统通知] 21天前
查看: 5020|回复: 7
文件“打包”后，零件和工程图不能关联了
在线时间 小时
马上注册，结识高手，享用更多资源，轻松玩转三维网社区。
才可以下载或查看，没有帐号？
装配体打包到另外一个文件夹后，把装配体名称更改了，打开工程图后，显示不出来图形，也没有查找提示的对话框，不知道怎么弄，请教一下，急，谢谢了！
当他人从你分享的链接访问本页面时，每一个访问者的点击，你将获得[5三维币]的奖励,一个IP计算一次.
楼主的相关阅读
此贴共有 5 人浏览过
在线时间 小时
你要用SW explore来修改名称
在线时间 小时
修改名称的时候，请注意:如图
QQ截图29.jpg (116.58 KB, 下载次数: 3)
10:15 上传
在线时间 小时
修改名称是不行的。打包可以存为压缩文件，在打包时增加前缀或后缀。
在线时间 小时
你打包时有没有携带工程图
在线时间 小时
头像被屏蔽
提示: 作者被禁止或删除 内容自动屏蔽
在线时间 小时
SolidWorks--打包，然后再列表的文件名称处修改新的工程图和零件的名称。
这个也可以，改完之后也是关联的。
在线时间 小时
复杂文件打包是有问题，我前阶段打了一个，当时没检查，发现丢了个别零件
移动客户端
Copyright &
All Rights ReservedPackaging - 6. Reference
To understand some of the fields, you need some knowledge of the
build process Fink uses. It consists of five phases: unpack, patch,
compile, install and build. The example paths below are for an
installation in /sw and the package gimp-1.2.1-1.
In the unpack phase the directory /sw/src/fink.build/gimp-1.2.1-1 is created
and the source tarball(s) are unpacked there. In most cases, this will
create a directory gimp-1.2.1 w all following
steps will be executed in that directory
(i.e. /sw/src/fink.build/gimp-1.2.1-1/gimp-1.2.1). Details can be controlled with
the SourceDirectory, NoSourceDirectory and SourceNExtractDir
In the patch phase the source is patched so that it will
build on Darwin. The actions specified by the UpdateConfigGuess,
UpdateLibtool, Patch and PatchScript fields will be executed, in that
In the compile phase the source is configured and
compiled. Usually this means calling the configure script
with some parameters and then issuing a make command. See the
CompileScript field description for details.
If test suites are enabled
for the build (a new feature in fink 0.25, currently achieved by building in
maintainer mode), the TestScript will be run immediately after the
CompileScript.
In the install phase the package is installed to a temporary
directory, /sw/src/fink.build/root-gimp-1.2.1-1 (= %d). (Note the "root-" part.)
All files that would normally be installed to /sw are installed in
/sw/src/fink.build/root-gimp-1.2.1-1/sw (= %i = %d%p) instead. See the
InstallScript field description for details.
(Introduced in fink 0.9.9. It is possible to generate several
packages from a single package description using the SplitOff
Towards the end of the install phase, separate install directories
are created for each package being created, and files are moved to
the appropriate directory.)
In the build phase a binary package file (.deb) is built
from the temporary directory. You can't influence this step directly,
but various information from the package description is used to
generate a control file for dpkg.
We have divided the list of fields into several categories.
The list of fields is not necessarily complete. :-)
Initial Data:
FieldValuePackage
The package name.
May contain lowercase letters, numbers and the special characters '.',
'+' and '-'.
No underscores ('_'), no capital letters.
Required field.
Percent expansion is applied to this field for %N, %{Ni}, %type_raw[],
and %type_pkg[] only.
As per Fink packaging policy, a given package must always
compile with the same options enabled. If you have multiple variants
for a package (see documentation for the Type field), you
must encode the specific variant info into the Package
field (see documentation for the %type_pkg[] percent expansion). That
way each variant has a unique name the package name indicates which
variant option(s) are included. Note that use of the %type_pkg[] and
%type_raw[] percent expansions in the Package field is
new and severely incompatible with older versions of fink, so such
package descriptions must be embedded in a InfoN field
with N&=2.
The upstream version number.
Same limitations as the Package field.
Required field.
Note that some programs use nonstandard version numbering schemes
that may cause sorting confusion or that contain characters that are
not allowed in this field. In these situations, when writing the
Fink package, you must convert the upstream value to one that is
acceptable and that allows the versions to be arranged in the
correct order. When in doubt about how version strings will be
sorted, you can use the dpkg command at a shell
prompt. For example,
dpkg --compare-versions 1.2.1 lt 1.3 && echo "true"
will print "true" because version string "1.2.1"
is less than "1.3". See the dpkg manpage for
more details.
The package revision.
Increase this when you make a new description for the same upstream
Revision numbers start at 1.
Required field.
Fink's policy is that any time you make a change to the
.info file that results in changes to the
binary (compiled) form of a package (the .deb
file), you must increase Revision. This
includes changing the Depends or other package lists,
and adding,
removing, or renaming splitoff packages or shifting files among
them. When migrating a package to a new tree (from 10.2 to 10.3, for
example) involves such changes, you should
increase Revision by 10 (or some other large number) in the newer tree in order to
leave space for future updates to the package in the older
Architecture
A comma-separated list of fink architecture(s) for which the package
(and any splitoff packages) are intended.
As of fink-0.29.5, the valid values for architecture are powerpc,
i386, and x86_64.
If this field is present and not blank after
conditional handling, fink will ignore the package description(s) if
the local fink architecture is not listed. If the field is omitted
or the value is blank, all architectures are assumed.
One common use of this field will be for packages which
require a compiler earlier than gcc-4.0 (or packages which depend on such
packages), which should be declared to have architecture
This field supports the standard conditional syntax for any value in
the value list and percent-expansions can be used (see
the Depends field for more information). In this manner,
certain variants can be restricted to certain architectures. For
Package: foo-pm%type_pkg[perl]
Type: perl (5.8.8 5.10.0)
Architecture: (%type_pkg[perl] = 5100) x86_64
will result in the field for the foo-pm5100 variant
being x86_64 and the field being blank for the foo-pm588
variant. Remember that when the field is blank, all architectures
are permitted.
The example above gives a very common use of this field: since
some modules for system-perl 5.10.0 on 10.6 do not build as 32-bit (i386),
this field allows limiting multiple-type perl packages to specific
Distribution
A comma-separated list of distribution(s) for which the package
(and any splitoff packages) are intended.
At present, the only valid values for distribution are
. If this field is present and not blank after
conditional handling, fink will ignore the package description(s) if
the local machine distribution is not listed. If the field is omitted
or the value is blank, all distributions are assumed.
(Introduced in fink 0.26.0.)
Since Fink's 10.7, 10.8, and 10.9 distributions share
a common set of finkinfo files, the most common use of this field will be for
packages which are suitable for one of those distributions but not the
This field supports the standard conditional syntax for any value in
the value list and percent-expansions can be used (see
the Depends field for more information). In this manner,
certain variants can be restricted to certain distributions. For
Package: foo-pm%type_pkg[perl]
Type: perl (5.12.3 5.12.4)
Distribution: (%type_pkg[perl] = , (%type_pkg[perl] =
will result in the Distribution field for the foo-pm5123 variant
being 10.7, 10.8 and the field being blank for the
foo-pm5124 variant.
Since python 2.5 is not available in the 10.7+ distributions, and the
available perl versions vary by distribution, these package types provide
a common use of this field.
For reference, we note the availabilty of
various perl versions in the 10.3 through 10.9 distributions
(bolded systems indicate system-perl at that version):
perl 5.6.0:
perl 5.8.0:
perl 5.8.1:
10.3, 10.4
perl 5.8.4:
10.3, 10.4
perl 5.8.6:
10.3, 10.4, 10.5
perl 5.8.8:
10.4, 10.5, 10.6
perl 5.10.0:
10.5, 10.6
perl 5.12.3:
10.7, 10.8, 10.9
perl 5.12.4:
10.7, 10.8, 10.9
perl 5.16.2:
10.7, 10.8, 10.9, 10.10
perl 5.18.2:
10.7, 10.8, 10.9, 10.10
A way to include all supported variants in a single finkinfo file is as follows.
Package: foo-pm%type_pkg[perl]
Type: perl (5.8.8 5.10.0 5.12.3 5.12.4 5.16.2)
Distribution: &&
(%type_pkg[perl] = 588) 10.6,
(%type_pkg[perl] = ,
(%type_pkg[perl] = , (%type_pkg[perl] = , (%type_pkg[perl] = ,
(%type_pkg[perl] = , (%type_pkg[perl] = , (%type_pkg[perl] = ,
(%type_pkg[perl] = , (%type_pkg[perl] = , (%type_pkg[perl] =
Note that we do not include old
distributions, such as 10.2 or 10.4-transitional, since the versions of
fink which are relevant for them do not recognize this field.
Introduced in fink 0.12.0.
This optional field can be used to specify the epoch of the package
(which defaults to 0 if not specified). For more information refer to
Because Fink and some of the underlying Debian tools use
name-version-revision as the unique identifier of a package, you must
not create a package that differs from another solely by its epoch.
When used in a version string, the Epoch appears before the Version
value, separated by a colon (1:3.14-2). Note that the Epoch is not part
of %v (or (%f). If you add an Epoch field to
a package description file, you may have to adjust versioned
dependencies on the packages in it. For example, if you
add Epoch: 1 and foo-dev declares Depends:
foo-shlibs (= %v-%r), you will need to rewrite that
as Depends: foo-shlibs (= %e:%v-%r).
Description
A short description of the package (what is it?). This is a one-line
description that will be displayed in lists, so it must be short and
informative. It should be less than 45 chars and must be less than
60. It is not necessary to repeat the package name in this field - it
will always be displayed in proper context. Required field.
This can be set to bundle.
Bundle packages are used to group a set of related packages together.
They only have dependencies, but no code and no installed files.
The fields Source, PatchScript, CompileScript, InstallScript and
related ones are ignored for bundle packages.
nosource is a very similar type.
It indicates that there is no source tarball, so nothing is fetched
and the unpack phase creates just an empty directory.
However, the patch, compile and install phases are executed normally.
This way you can bring in all the code with a patch, or just create
some directories in the InstallScript.
Since fink 0.18.0, you can get the same behavior by setting
Source: none. This allows you to use "Type" for other
purposes (Type: perl, etc.)
Since fink 0.9.5 there is type perl which causes
alternate default values for the compile and install scripts to be used.
Beginning in fink 0.13.0, there is a new variant of this type,
perl $version, where $version is a specific version of perl
consisting of three numbers separated by periods, e.g.,
perl 5.6.0.
Beginning in a CVS version of fink after fink-0.19.2, the language/language-version use has
been generalized to allow any Maintainer-defined types and associated
subtypes and more than a single type for a given package. The type and
subtype are each arbitrary strings of non-whitespace characters (but
parentheses, commas, braces, and percent signs should not be used); no
percent-expansion is performed, and the type (not subtype) values
are converted to all-lowercase.
Multiple type values (each with an
optional whitespace-separated subtype) are specified in a
comma-separated list.
In addition, the concept of "variants" exists, where a
single .info file describes a family of related packages with various
options enabled. The key to this whole process is the use of a list of
subtypes. Instead of a single string, one uses a space-separated list
of strings in parentheses. Fink clones the package description file
for each subtype in the list and replaces this list with that single
subtype. For example:
Type: perl (5.12.3 5.12.4)
yields two package descriptions, one that behaves as if Type:
perl 5.12.3 and the other Type: perl 5.12.4. The special
subtype list "(boolean)" stands for a list containing the
type itself and a period, so the following two forms are identical:
Type: -x11 (boolean)
Type: -x11 (-x11 .)
Subtype list expansion/package
if there are
multiple types with subtype lists, you will get all combinations:
Type: -ssl (boolean), perl (5.12.3 5.12.4)
One can access the specific variant subtype in other fields using the
%type_raw[] and %type_pkg[] pseudo-hashes. Here are two example .info
fragments:
Package: foo-pm%type_pkg[perl]
Type: perl (5.12.3 5.12.4)
Depends: perl%type_pkg[perl]-core
Package: bar%type_pkg[-x11]
Type: -x11 (boolean)
Depends: (%type_raw[-x11] = -x11) x11
CompileScript:
#!/bin/bash -ev
if [ "%type_raw[-x11]" == "-x11" ]; then
./configure %c --with-x11
./configure %c --without-x11
Starting in fink 0.26.0, there is a special Type: -64bit
which controls a new percent expansion %lib and also
changes the default value of LDFLAGS.
When combined
with the new construction %type_num[], this allows a single .info file
to build both a 32-bit version of a library and a 64-bit version.
Here's some sample code:
Package: foo%type_pkg[-64bit]
Type: -64bit (boolean)
Depends: (%type_raw[-64bit] = -64bit) 64bit-cpu
ConfigureParams: --libdir='${prefix}/%lib'
SplitOff: &&
Package: %N-shlibs
Files: %lib/libfoo.*.dylib
Shlibs: &&
%p/%lib/libfoo.1.dylib 1.0.0 %n (&= 1.0-1) %type_num[-64bit]
Note that Type: -64bit is generally not appropriate for
the x86_64 architecture, since in that case
libraries are being built 64-bit by default
and stored in %i/lib.
This field gives the nature of the license under which the package is
distributed.
The value must be one of the values described in
earlier in
this document.
Additionally, this field must only be given if the package actually
complies to the packaging policy in these respects, i.e. a copy of the
license is installed in the doc directory for the package.
Maintainer
The name and e-mail address of the person responsible for the package.
This field is required, and there must be exactly one name and address
in the following format:
Firstname Lastname &user@host.domain.com&
This field allows fink to implement backward-incompatible syntax
changes in package description files. A given version of fink is
configured with the maximum integer "N" that it can handle. Any
package in a higher InfoN field will be ignored, so this mechanism
should only be used when necessary, lest people with older versions of
fink be needlessly alienated. To use this mechanism, embed
the entire package description in the desired InfoN field. See the
"File Format" section earlier in this document for a description of
the syntax for multiline fields.
Here are the features added for each InfoN level, along with the
earliest version of fink that supports it:
Info2 (fink&=0.20.0): Ability to use percent-expansions
in the main Package field of the .info file and the
ability to use the %type_* percent-expansions in
the Package field of SplitOff
(and SplitOffN) packages.
Info3 (fink&=0.25.0): Can indent nicely in .info files,
no more support for RFC-822 multi-lines, and can put comments in
pkglist fields.
Info4 (fink&=0.26.2): adds %V expansion, and permits
%lib in ConfigureParams field.
Dependencies:
FieldValueDepends
A list of packages which must be installed before this package can be
built. Percent expansion is performed on this field (as well as the
other package list fields in this section: BuildDepends, RuntimeDepends,
Provides, Conflicts, Replaces, Recommends, Suggests, and Enhances.
Usually, this is just a comma-separated list for plain package names,
but Fink now supports alternatives and version clauses with the same
syntax as dpkg.
A fully featured example:
Depends: &&
daemonic (&= ),
emacs | xemacs
The layout above is the preferred format for the Depends
and similar fields. The field uses the multi-line field declarators
&& and each package is placed in alphabetical order
on its own indented line. If the field only has a single entry, the
simplified Field: value format may be used.
Note that there is no way to express real optional dependencies.
If a package works both with and without another package, you must
either make sure that the other package is not used even when it is
present or add it to the Depends field.
If you want to offer the user both options, make two separate
packages, e.g. wget and wget-ssl.
Order of operations: logical "OR" (list of alternatives) has
a higher precedence (binds more tightly) than the logical
"AND" between each package (or set of alternatives) in the
comma-separated list. Unlike the use of parentheses in arithmetic,
there is no way to specify alternative groups of packages or otherwise
change the order of operations in Depends and related
Starting with a post-0.18.2 CVS version of fink, you can have
conditional dependencies. These are specified by placing
(string1 op string2) before a package name. Percent
expansion is performed as usual and then the two strings
(neither of which can be null) are compared
according to the op operator: &&, &=, =, !=,
&&, &=. The immediately-following package is only considered
as a dependency if the comparison is true.
You can use this format to simplify maintaining several similar
packages. For example, the packages elinks and elinks-ssl could both list:
Depends: &&
expat-shlibs,
(%n = elinks-ssl) openssl097-shlibs
would have the same effect as having elinks list:
Depends: expat-shlibs
and elinks-ssl list:
Depends: expat-shlibs, openssl097-shlibs
As an alternative syntax, you can also specify (string),
which is "true" if string is non-null. For example:
Package: nethack%type_pkg[-x11]
Type: -x11 (boolean)
Depends: (%type_pkg[-x11]) x11
would set the package x11 as a dependency for the nethack-x11 variant
but not for the nethack variant.
Note that when using Depends/BuildDepends for shared library packages
for which more than one major-version is available, you must
not do the following:
Package: foo
Depends: id3lib3.7-shlibs | id3lib4-shlibs
BuildDepends: id3lib3.7-dev | id3lib4-dev
even if your package could work with either library. Pick one
(preferably the highest version that can be used successfully) and
use it consistently in your package.
As explained in the , only one of the
-dev packages can be installed at a time, and each has links of the
same name that could point to different filenames in the associated
-shlibs package. When compiling package foo, the actual filename (in
the -shlibs package) gets hard-coded into the foo binary. That means
the resulting package needs the specific -shlibs package associated
with the -dev that was installed at compile-time. As a result, one
cannot have a Depends that indicates that either one
will suffice.
In the past, non-essential packages implicitly depended on the
this is no longer true.
BuildDepends
Introduced in fink 0.9.0.
A list of dependencies that is applied at build time only.
This can be used to list tools (e.g. flex) that must be present to
build the package, but which are not used at run time.
Supports the same syntax as Depends.
If a build is being done
with test suites enabled, the dependencies in the TestDepends
field will be added to this list.
RuntimeDepends
Introduced in fink 0.32.0.
A list of dependencies that is applied at run time only,
that is, when the package is being installed.
This can be used to list packages that must be present to
run the package, but which are not used at build time.
Supports the same syntax as Depends.
A comma-separated list of package names that this package is
considered to "provide".
If a package named "pine" specifies Provides: mailer,
then any dependency on "mailer" is considered satisfied when "pine" is
installed.
You'll usually also want to name these packages in the "Conflicts" and
the "Replaces" field.
Note that there is no versioning data associated with Provides
items. They do not inherit from the parent package that contains the
Provides list nor is there a syntax for specifying an arbitrary version
in the Provides field itself. Further, a dependency that contains a
version specification is not satisfied by a package that Provides that
needed package name. As a result, having many variants provide a common surrogate package may be harmful, because it precludes the use of versioned dependencies. For example, if foo-gnome and foo-nognome both have "Provides: foo", another package with "Depends: foo (& 1.1)" will not work.
A comma-separated list of package names that must not be installed at
the same time as this package.
For virtual packages it is allowed to list the names of the provided
they will be handled appropriately.
This fields also supports versioned dependencies like the Depends
field, but not alternatives (wouldn't make sense).
If a package is listed in its own Conflicts, it will be (silently)
removed from that list. (Introduced in a post-0.18.2 CVS version of
Note: Fink itself currently ignores this field.
However, it is passed on to dpkg and will be handled accordingly.
In summary, it only effects run-time, not build-time.
BuildConflicts
A list of packages that must not be installed while this package is
being compiled. This can be used to prevent ./configure
or the compiler from seeing undesired library headers or to avoid use
of a version of a tool that is known to be broken (for example, a bug
in a certain version of sed).
If a build is being done
with test suites enabled, the packages in the TestConflicts
field will be added to this list.
This is used together with "Conflicts", when this package not only
takes over the function of the conflicting package, but also has some
common files.
Without this field, dpkg may generate errors when installing the
package because files are still owned by the other package.
It is also a hint that the two packages involved are genuine
alternatives and one can be removed in favor of the other.
If a package is listed in its own Replaces, it will be (silently)
removed from that list. (Introduced in a post-0.18.2 CVS version of
Note: Fink itself currently ignores this field.
However, it is passed on to dpkg and will be handled accordingly.
In summary, it only effects run-time, not build-time.
Recommends, Suggests, Enhances
These fields specify additional package relations in the same style as
the other dependency fields.
These three relations don't affect actual installation via
dpkg or apt-get.
However, they are used by dselect and other frontends to
help the user make sensible choices.
Pre-Depends
A special variation of the Depends field with more strict semantics.
This field must only be used after the case has been discussed on the
developer mailing list and a consensus has been reached that it is
necessary.
A boolean value that denotes essential packages. Essential
packages are installed as part of the bootstrap process. dpkg
will refuse to remove essential packages from the system unless
special flags are used to override this.
In the past, non-essential packages implicitly depended on the
this is no longer true.
BuildDependsOnly
Introduced in fink 0.9.9.
A boolean value which indicates that no other packages should Depend on
this one, they should only BuildDepend.
Unlike usual boolean fields, BuildDependsOnly is
tri-state: leaving it undefined (not specifying it at all) is
different than defining it as logically false. See the
more information.
As of fink 0.20.5, the presence or absence of this field, and its value
if present, are recorded into the .deb
file when the package is built.
Therefore, if you change the value of
BuildDependsOnly or if you add or remove it,
you must increase the revision number of the package.
Unpack Phase:
FieldValueCustomMirror
A list of mirror sites. Each mirror site appears on a separate line,
in the following format: &location&: &url&.
location can be a continent code (e.g. nam), a
country code (e.g. nam-us),
mirrors are tried in that order.
CustomMirror: &&
nam-US: ftp://ftp.fooquux.com/pub/bar
asi-JP: ftp://ftp.qiixbar.jp/pub/mirror/bar
eur-DE: ftp://ftp.barfoo.de/bar
Primary: ftp://ftp.barbarorg/pub/
The standard continent and country codes are listed in
/sw/lib/fink/mirror/_keys, which is part of the
fink or fink-mirrors package.
An URL to the source tarball. It should be a HTTP or FTP URL, but
Fink doesn't really care - it just passes the URL to wget. This field
supports a special URL scheme for mirrors:
mirror:&mirror-name&:&relative-path&. This will
look up the mirror setting for mirror-name in Fink's
configuration, append the relative-path part and use that as
the actual URL. The known mirror-names are listed in
/sw/lib/fink/mirror/_list, which is part of the fink or fink-mirrors
package. Alternatively, using custom as the
mirror-name will cause Fink to use the CustomMirror
Before the URL is used, percent expansion takes place. Remember that
%n includes all %type_ variant data, so you may want to use %{ni} here
(perhaps with some specific %type_ expansions).
Since fink 0.18.0, Source: none has the special meaning
that there is no source to fetch. See the description of the
Type field for more information.
The value gnu is a shorthand for
mirror:gnu:%n/%n-%v.tar.gz; gnome is a shorthand for
mirror:gnome:stable/sources/%n/%n-%v.tar.gz. The
default is %n-%v.tar.gz (i.e. a manual
download).
This implicitly-defined Source form is deprecated
(explicitly-stated simple filename/manual download is still okay).
Sources that are only needed in order to run test suites should
use TestSource and related fields, inside the
InfoTest block.
If a package consists of several tarballs, name them with these
additional fields, starting with N = 2. So, the first tarball (which
should be some kind of "main" tarball) goes into Source, the
second tarball in Source2 and so on. The rules are the same
as for Source, only that the "gnu" and "gnome" shortcuts are not
expanded - that would be useless anyway. Starting with a CVS version
of fink after 0.19.2, you may use arbitrary (not necessarily
consecutive) integer values of N &= 2. However, you still may not have
duplicates.
SourceDirectory
Must be used when the tarball expands to a single directory, but
the directory's name is different from the basename of the tarball.
Usually, a tarball named "foo-1.0.tar.gz" will produce a directory
named "foo-1.0". If it produces a directory with a different name,
specify it with this parameter. Percent expansion is performed on this
NoSourceDirectory
Set this boolean parameter to a true value if the tarball does not
expand to a single directory. Usually, a tarball named "foo-1.0.tar.gz"
will produce a directory named "foo-1.0". If it just unpacks the files
to the current directory, use this parameter and set it to a boolean
true value.
SourceNExtractDir
Normally, an auxiliary tarball will be extracted in the same
directory as the main tarball. If you need to extract it in a
specific subdirectory instead, use this field to specify
it. Source2ExtractDir corresponds to the Source2 tarball, as one would
expect. See ghostscript, vim and tetex for examples of usage.
SourceRename
This field can rename a source tarball on the fly. This is useful
if for example the version of the source is encoded in the directory name on
the server, but the tarball itself has the same name for all versions, e.g.
http://www.foobar.org/coolapp/1.2.3/source.tar.gz. To circumvent the problems
caused by this, you would then use something like
SourceRename: %n-%v.tar.gz
In the above example this would result in the tarball being stored under
/sw/src/coolapp-1.2.3.tar.gz as one would expect.
SourceNRename
This is just the same as the SourceRename field, except that it
is used to rename the tarball specified by the corresponding SourceN
field. See context or hyperref for examples of usage.
Source-MD5
Introduced in fink 0.10.0.
With this field you can specify the MD5 checksum of the source file. This
information is then used by Fink to detect incorrect source files, that is,
tarballs not matching the one the package creator used. Common causes for this
problem include: incompletely upstream maintainers silently
a troja and so on.
A typical usage example looks like this:
Source-MD5: dafe64522abac
To compute the checksum, the md5sum tool is used. If you want to
determine the checksum of the tarball /sw/src/apache_1.3.23.tar.gz,
you run the following command (displayed with output here):
fingolfin% md5sum /sw/src/apache_1.3.23.tar.gz
dafe64522abac
/sw/src/apache_1.3.23.tar.gz
As you can see, the value to the left is exactly the value you need.
SourceN-MD5
Introduced in fink 0.10.0.
This is just the same as the Source-MD5 field, except that it
is used to specify the MD5 checksum of the tarball specified by the
corresponding SourceN field.
TarFilesRename
Introduced in fink 0.10.0.
This field only applies to source files that are using the tar format
With this field you can rename files in the given source tarball during
the extraction of the tarball. This is very useful to work around
the fact that the HFS+ file system is not case sensitive, as files like
install and INSTALL will
collide on a standard Mac OS X system. With this field you can avoid
these issues without having to repackage the tarball (as was done in
the past in such cases).
In this field you simply specify a list of files that are to be renamed. You
can make use of wildcards. By default any given file will be renamed to its
current name with _tmp appended. You can override this default
by using the same syntax as in the Files and DocFiles
fields, namely by writing the old filename followed by a : and then followed by
the new filename.
TarFilesRename: foo bar.* qux:quux
Tar2FilesRename: directory/INSTALL:directory/INSTALL.txt
TarNFilesRename
Introduced in fink 0.10.0.
This is just the same as the TarFilesRename field, except that it
is used for the tarball specified by the corresponding
SourceN field.
Patch Phase:
FieldValueUpdateConfigGuess
A boolean value. If true, the files config.guess and config.sub
in the build directory will be replaced with versions that know about
Darwin. This happens in the patch phase and before the PatchScript
is run. Only use this when you know it is necessary,
i.e. when the configure script fails with a "unknown host"
UpdateConfigGuessInDirs
Introduced in a post-0.9.0 CVS version.
A list of subdirectories.
This does the same as UpdateConfigGuess, but is useful for packages
that have outdated config.guess files in several directories
throughout the source tree.
Previously you had to copy/move the files there manually in the
PatchScript.
With this new field you can just list the directories.
Use . to update files in the build directory itself.
UpdateLibtool
A boolean value. If true, the files ltconfig and ltmain.sh in the
build directory will be replaced with versions that know about
Darwin. This happens in the patch phase and before the PatchScript
is run. Only use this when you know that the package needs
it. Some packages can be broken by overwriting the libtool scripts
with mismatching versions. See the
for further information.
UpdateLibtoolInDirs
Introduced in a post-0.9.0 CVS version.
A list of subdirectories.
This does the same as UpdateLibtool, but is useful for packages
that have outdated libtool 1.3.x scripts in several directories
throughout the source tree.
Previously you had to copy/move the files there manually in the
PatchScript.
With this new field you can just list the directories.
Use . to update files in the build directory itself.
UpdatePoMakefile
A boolean value.
If true, the file Makefile.in.in in the
subdirectory po is replaced with a patched version.
This happens in the patch phase and before the PatchScript is run.
The patched version respects DESTDIR and makes sure that message
catalogs end up in /sw/share/locale, not
/sw/lib/locale.
Before using this field, make sure that you won't break the package
and that it's really required.
You can run diff to find the differences between the
package's version and Fink's version (in
/sw/lib/fink/update).
The filename of a patch to be applied with patch -p1
&patch-file. This shoul the
appropriate path (the same directory where the .info file
is located) will be prepended automatically. Percent expansion is
performed on this field, so a typical value is simply
%f.patch or %n.patch. The patch is applied
in a separate step before the PatchScript is run (if any).
Remember that %n includes all %type_ variant data, so you may want to
use %{ni} here (perhaps with some specific %type_ expansions). It's
easier to maintain a single patchfile and then make variant-specific
changes in PatchScript than to have a separate patchfile
for each variant.
As of fink-0.29.0, this field should not be used.
Use PatchFile instead. Support for Patch
will be removed in the future.
The same syntax as the Patch field. The full path to this
file is available using the %{PatchFile} percent
expansion--do not use %a to access this file.
Unlike Patch, PatchFile is applied as part
of PatchScript. Fink checks that the listed file exists,
is readable, and that its checksum matches
the PatchFile-MD5 field.
You may not use both Patch and PatchFile in
the same package description. Any package that
uses PatchFile must declare at least
BuildDepends: fink (&= 0.24.12). Giving a higher version
requirement is allowed if it is necessary for other reasons.
PatchFileN
If a package has several patch files, name them with these additional
fields, starting with N = 2. So, the first patch file goes into
PatchFile, the second patch file in PatchFile2
and so on.
Any package that uses PatchFileN must
declare at least BuildDepends: fink (&= 0.30.0). Giving
a higher version requirement is allowed if it is necessary for other
PatchFile-MD5
The MD5 checksum of the file given in the PatchFile
field. This field is required if PatchFile is used.
(Introduced in fink-0.24.12)
PatchFileN-MD5
The MD5 checksum of the file given in the PatchFileN
field. This field is required if PatchFileN is used.
(Introduced in fink-0.30.0)
PatchScript
A list of commands that are run in the patch phase. This is the place
to put commands that patch or otherwise modify the package source. See
below. Before the commands are executed,
takes place. If
a PatchFile field exists, the
default PatchScript is:
patch -p1 & %{PatchFile}
If one or more PatchFileN fields are used, the
following is appended as needed to the default script:
patch -p1 & %{PatchFileN}
If there is no PatchFile, the default is blank. If you
have an explicit PatchScript, you must apply
the PatchFile(s) explicitly.
Compile Phase:
FieldValueSetENVVAR
Causes certain environment variables to be set in the
compile and install phases. This can be used to pass compiler flags
etc. to configure scripts and Makefiles. Currently supported variables
CC, CFLAGS, CPP, CPPFLAGS, CXX, CXXFLAGS, DYLD_LIBRARY_PATH, JAVA_HOME,
LD, LDFLAGS, LIBRARY_PATH, LIBS, MACOSX_DEPLOYMENT_TARGET, MAKE,
MFLAGS, MAKEFLAGS.
The value you specify is subject to the
percent expansion described in the last section. A common example:
SetLDFLAGS: -Wl,-strip_dead_dylibs
Some environment variables have default preset values.
If you specify a value for one of these, it will be
prepended to the default value.
The preset variables (and their default values) are:
CPPFLAGS: -I%p/include
LDFLAGS: -L%p/lib
Starting in fink 0.26.0, there is one exception to these defaults:
if Type: -64bit is set to -64bit, then the
default value of LDFLAGS is -L%p/%lib -L%p/lib
Finally, MACOSX_DEPLOYMENT_TARGET is set to a default value depending
on which version of OSX is being run, but setting a value for it for
a package will override (rather than prepend to) the default value.
NoSetENVVAR
When set to a true value, deactivates the default values for the preset
variables (such as
CPPFLAGS, LDFLAGS, CXXFLAGS
mentioned above). For
example, if you want LDFLAGS to
remain unset, specify NoSetLDFLAGS: true .
UseMaxBuildJobs
When set to a true value, appends -jN, where N
is the value from the fink.conf field MaxBuildJobs,
to the environment variable MAKEFLAGS during CompileScript and TestScript.
This value is added to MAKEFLAGS even if the field NoSetMAKEFLAGS:
true is used. As of fink & 0.31.2, if the field is not present or
blank, the default is True.
BuildAsNobody
In fink &= 0.33.0, when set to a false value, causes fink
to build as root rather than as the underprivileged fink-bld user.
If this field is not present, its value defaults to true, indicating
that the package should be built as fink-bld.
In earlier fink versions, this field does nothing.
ConfigureParams
Additional parameters to pass to the configure script. (See
CompileScript for details.)
For packages not of Type: Perl, the parameter
--prefix=%p is prepended to this value.
As of fink & 0.13.7, this field will also work with perl modules
Type: Perl; the default perl Makefile.PL
string is prepended to the value supplied for ConfigureParams.
If a build is being done
with test suites enabled, the value of the TestConfigureParams
field will be appended to the normal ConfigureParams value.
Starting in fink-0.22.0, this field supports conditionals. The
syntax is the same as that used in the Depends and
other package-list fields. The conditional expression only applies
to the whitespace-delimited "word" immediately following
it. For example
Type: -x11 (boolean)
ConfigureParams: --mandir=%p/share/man (%type_pkg[-x11]) --with-x11 --disable-shared
will always pass the --mandir and --disable-shared flags, but only pass --with-x11 in the -x11 variant.
This field supports placing parameters into multiple lines using multi-line field declarators. The field is handled as a shell command line and uses \ to separate lines:
ConfigureParams: &&
--mandir=%p/share/man \
(%type_pkg[-x11]) --with-x11 \
--disable-shared
Note: do not place conditional parameters as the last line when using the multi-line field format. In instances when the conditional evaluates as false, the parameter immediately following is not evaluated and this breaks the shell.
This field specifies the GCC-ABI used by C++ code in this package.
(It is needed because that ABI has changed twice, and any libraries
which you link to containing C++ code must be compiled with the same ABI
you are currently using.)
The allowed values are:
2.95.2 (or 2.95),
Our understanding is that the GCC authors intend to stabilize the GCC-ABI
we can hope that it won't change again.
The GCC field does not have a default value, per se, since it is ignored
if it is not set.
However, for each tree, there is an expected value
for GCC corresponding to the default g++ compiler for that tree.
The expected values for the various package trees are:
2.95 in the 10.1 tree, 3.1 in the 10.2 tree,
3.3 in the 10.2-gcc3.3, 10.3, and 10.4-transitional
trees, and 4.0 in the 10.4 and 10.7 trees.
Note that when the GCC value is different from the expected value, the compiler
must be specified within the package (typically by setting the CC or CXX
flags), and a dependency on one of the (virtual) gcc packages should be
specified.
As of fink 0.13.8, when this flag is present, the version of gcc
is tested using gcc_select, and fink exits with an error
if the wrong version is present.
This field was added to fink to aid maintainers
in tracking the transition between the gcc
compilers, which introduced a binary incompatibility between libraries
that involve C++ code which is not reflected in the versioning
CompileScript
A list of commands that are run in the compile phase. This is the
place to put commands that configure and compile the package. See
below. Before the commands are executed,
takes place. Normally the
default is:
./configure %c
This is appropriate for packages that use GNU autoconf.
For packages with of type perl (as specified via the Type field)
with the perl version not specified,
the default instead (as of fink 0.13.4) is:
perl Makefile.PL PREFIX=%p \
INSTALLPRIVLIB=%p/lib/perl5 \
INSTALLARCHLIB=%p/lib/perl5/darwin \
INSTALLSITELIB=%p/lib/perl5 \
INSTALLSITEARCH=%p/lib/perl5/darwin \
INSTALLMAN1DIR=%p/share/man/man1 \
INSTALLMAN3DIR=%p/share/man/man3 \
INSTALLSITEMAN1DIR=%p/share/man/man1 \
INSTALLSITEMAN3DIR=%p/share/man/man3 \
INSTALLBIN=%p/bin \
INSTALLSITEBIN=%p/bin \
INSTALLSCRIPT=%p/bin
If the type is perl $version with the version specified
(e.g., $version might be 5.6.0),
then the default becomes:
perl$version Makefile.PL \
PERL=perl$version PREFIX=%p \
INSTALLPRIVLIB=%p/lib/perl5/$version \
INSTALLARCHLIB=%p/lib/perl5/$version/$perlarchdir \
INSTALLSITELIB=%p/lib/perl5/$version \
INSTALLSITEARCH=%p/lib/perl5/$version/$perlarchdir \
INSTALLMAN1DIR=%p/share/man/man1 \
INSTALLMAN3DIR=%p/share/man/man3 \
INSTALLSITEMAN1DIR=%p/share/man/man1 \
INSTALLSITEMAN3DIR=%p/share/man/man3 \
INSTALLBIN=%p/bin \
INSTALLSITEBIN=%p/bin \
INSTALLSCRIPT=%p/bin
where $perlarchdir is "darwin" for versions 5.8.0 and
earlier, and is
"darwin-thread-multi-2level" for versions 5.8.1 and later.
NoPerlTests
Introduced in fink & 0.13.7.
A boolean value, specific for perl module packages.
If true, the make test portion
of the CompileScript will be ignored
for that specific perl module package.
Test Suites:
FieldValueInfoTest
Introduced in fink 0.25.
This field encapsulates information that will only be used when performing
a build with test suites enabled.
It contains other fields.
If present, this field must contain a TestScript.
All other fields are optional.
The following fields are allowed inside
TestScript: A script which runs the test suite.
This script should exit
with status 0 if the suite passes, 1 to indicate warnings, or any other
value to indicate failures serious enough to be considered fatal.
Because of this tri-state logic, you should explicitly set an exit value in
this script.
For instance, make check is a bad script,
since it will exit with status 1 if the check target doesn't exist.
make check || exit 2 would be a better script.
TestConfigureParams: A value which will be appended to ConfigureParams.
TestDepends and TestConflicts: Lists of packages that will be added to the BuildDepends or BuildConflicts lists.
TestSource: Extra sources necessary to run the test suite.
All of the
affiliated fields are also supported, so you must also specify
TestSource-MD5, and you may also have
TestSourceN and corresponding TestSourceN-MD5,
TestTarFilesRename, etc.
TestSuiteSize: Describes approximately how long the test suite takes to
Valid values are small, medium, and large.
This field is currently ignored.
Any other standard field.
If a field is specified both inside and outside
InfoTest, the value inside InfoTest will replace
the other value when test suites are active.
Here's an example:
InfoTest: &&
TestScript: make check || exit 2
TestConfigureParams: --enable-tests
Install Phase:
FieldValueUpdatePOD
Introduced in fink 0.9.5.
A boolean value, specific for perl module packages.
If true, this will add code to the install, postrm and postinst
scripts that maintains the .pod files provided by perl packages.
This includes adding and removing the .pod date from the central
/sw/lib/perl5/darwin/perllocal.pod file.
(If the type has been given as perl $version with a
specific version of perl such as 5.6.0,
then these scripts are adapted to deal with the central .pod file
/sw/lib/perl5/$version/perllocal.pod.)
InstallScript
A list of commands that are run in the install phase. This is the
place to put commands that copy all the necessary files into the
temporary dpkg directory for the package. See the
below. Before the commands are executed,
takes place. Normally the
default is:
make install prefix=%i
The default is appropriate for packages that use GNU autoconf.
For packages with of type perl (as specified via the Type field)
with the perl version not specified,
the default instead (as of fink 0.13.4) is:
make install INSTALLPRIVLIB=%i/lib/perl5 \
INSTALLARCHLIB=%i/lib/perl5/darwin \
INSTALLSITELIB=%i/lib/perl5 \
INSTALLSITEARCH=%i/lib/perl5/darwin \
INSTALLMAN1DIR=%i/share/man/man1 \
INSTALLMAN3DIR=%i/share/man/man3 \
INSTALLSITEMAN1DIR=%i/share/man/man1 \
INSTALLSITEMAN3DIR=%i/share/man/man3 \
INSTALLBIN=%i/bin \
INSTALLSITEBIN=%i/bin \
INSTALLSCRIPT=%i/bin
If the type is perl $version with the version specified
(e.g., $version might be 5.6.0),
then the default becomes:
make install INSTALLPRIVLIB=%i/lib/perl5/$version \
INSTALLARCHLIB=%i/lib/perl5/$version/$perlarchdir \
INSTALLSITELIB=%i/lib/perl5/$version \
INSTALLSITEARCH=%i/lib/perl5/$version/$perlarchdir \
INSTALLMAN1DIR=%i/share/man/man1 \
INSTALLMAN3DIR=%i/share/man/man3 \
INSTALLSITEMAN1DIR=%i/share/man/man1 \
INSTALLSITEMAN3DIR=%i/share/man/man3 \
INSTALLBIN=%i/bin \
INSTALLSITEBIN=%i/bin \
INSTALLSCRIPT=%i/bin
where $perlarchdir is "darwin" for versions 5.8.0 and
earlier, and is
"darwin-thread-multi-2level" for versions 5.8.1 and later.
If the package supports it, it is preferably to use make install
DESTDIR=%d instead.
AppBundles
Introduced in a post-0.23.1 version.
This field installs the specified application bundle(s) into
%p/Applications.
It will also create a
symlink to the /Applications/Fink directory.
AppBundles: build/*.app Foo.app
Introduced in fink 0.10.0.
This field is somewhat similar to DocFiles. It installs the specified jar
files into %p/share/java/%n.
JarFiles: lib/*.jar foo.jar:fooBar.jar
This will install all the jars that were in the lib directory and will install
foo.jar as fooBar.jar.
It also ensures that these jar files (specifically: all files in
%p/share/java/%n that end in .jar)
are added to the CLASSPATH environment variable. This allows tools like
configure or ant to properly detect the installed jar files.
This field provides a convenient way to install README or COPYING
files in the doc directory for the package,
%p/share/doc/%n.
The value is a space-separated list of files.
You can copy files from subdirectories of the build directory, but
they will end up in the doc directory itself, not in a subdirectory.
Shell wildcards are allowed.
It is also possible to rename single files on the fly by appending the
new name separated by a colon (:),
e.g. libgimp/COPYING:COPYING.libgimp.
This field works by appending appropriate install
commands to the InstallScript.
Introduced in fink 0.11.0.
This field declares the shared libraries which are installed in the
There is one line for each
shared library, which contains the -install_name of the
library and information about its binary compatibility. Shared
libraries that are "public" (i.e., provided for use by other packages)
have, separated by whitespace after the filename,
the -compatibility_version, versioned package
dependency information specifying the Fink package which provides
this library at this compatibility version, and the
library architecture.
(The library architecture may either be "32", "64", or
"32-64", if absent,
the value defaults to "32" under the powerpc and i386 machine architectures,
and to "64" under the x86_64 machine architecture.)
The dependency should
be stated in the form
foo (&= version-revision) where
version-revision refers to
the first version of a Fink package which made
this library (with this compatibility version) available.
The Shlibs declaration amounts to a promise
from the maintainer that a library with this name and a
-compatibility_version
of at least this number will always be found in later versions of this
Fink package.
Shared libraries that are "private" are denoted by an exclamation mark
preceeding the filename, and no compatilibity or versioning
information is given. See the
information.
RuntimeVars
Introduced in fink 0.10.0.
This field provides a convenient way to set environment variables to some static value at runtime (if you need more flexibility, refer to the ). As long as your package is installed, these variables will be set via the /sw/bin/init.[c]sh scripts.
The value of your variable can contain spaces (trailing ones are trimmed); also, percent expansion takes place. For example:
RuntimeVars: &&
SomeVar: %p/Value
AnotherVar: foo bar
will set two environment variables 'SomeVar' and 'AnotherVar' and their values
will be respectively '/sw/Value' (or whatever your prefix is) and 'foo bar'.
This field works by appending appropriate commands to the InstallScript.
These commands add a setenv/export line for each variable to the package profile.d scripts, so you can provide your own ones, they won't be overwritten. The lines are prepended to the scripts, you can thus use these variables in your scripts.
Introduced in fink 0.9.9.
Generate a second package from the same compile/install run.
For details about how this works, see the separate
Introduced in fink 0.9.9.
This is the same as SplitOff, used to generate a third,
fourth, etc. package from the same compile/install run. Starting with a
CVS version of fink after 0.19.2, you may use arbitrary (not
necessarily consecutive) integer values of N &= 2. However, you still
may not have duplicates.
Introduced in fink 0.9.9.
within a SplitOff or SplitOffN field,
this designates which files and directories
should be moved from the parent package's
installation
directory %I to the current installation directory %i.
Note that this
is executed after the InstallScript and the DocFiles of the parent package,
but before the InstallScript and Docfiles of the current package.
Build Phase:
FieldValuePreInstScript, PostInstScript, PreRmScript, PostRmScript
These fields specify pieces of shell scripts that will be called when
the package is installed, upgraded or removed.
Fink automatically adds the shell script header
#!/bin/sh, and calls set -e so any command
that fails will result in instant termination of the script.
Fink also adds an exit 0 at the end.
To indicate an error, exit from the script with a non-zero exit code.
The first parameter ($1) is set to a value indicating
what action is being performed.
Some possible values are install, upgrade,
remove and purge.
Note that there are more values, used during error rollback or when
removing a package in favor of another one.
The scripts are called at the following times:
PreInstScript: When the package is installed for the first time
and before upgrading the package to this version.
PostInstScript: After unpacking and setting up the package.
PreRmScript: Before the package is removed or upgraded to a later
PostRmScript: After the package was removed or upgraded to a later
To make it more clear, an upgrade invokes both the ...Inst scripts of
the new version and the ...Rm scripts of the old version.
Details can be found in the Debian Policy Manual,
Percent expansion is performed on the scripts.
Commands can generally be called without giving a full path.
A space-separated list of files that are user-modifiable configuration
Percent expansion
is performed on this field.
The files must be specified with an absolute path,
e.g. %p/etc/%n.conf.
The named files will receive special treatment by dpkg.
When a package is upgraded and the file has changed both on disk and
in the package, the user is asked which version to use and backups
of the file will be made.
When a package is "remove"d, the configuration files will remain on
Only a "purge" also removes the configuration files.
Lists the names of Info documents that the package installs in
%p/share/info.
This will add appropriate code to the postinst and prerm scripts to
maintain the Info directory file, dir.
Only use the un-numbered file in the case of split Info
documents. E.g. if a package has:
foo.info-1
foo.info-2
you should only use:
This feature is still in flux, more fields for finer control may be
added in the future.
DaemonicFile
Gives a service description for daemonic.
daemonic is used by Fink to create and remove
StartupItems for daemon processes (e.g. web servers).
The description will be added to the package as a file named
%p/etc/daemons/name.xml, where name is
specified by the DaemonicName field and defaults to the package
Percent expansion is performed on the contents of this field.
Note that you must add daemonic to the dependency list if
your package uses it.
DaemonicName
A name for the daemonic service description file.
See the description of DaemonicFile for details.
Additional Data:
FieldValueHomepage
The URL of the upstream home page of the package.
DescDetail
A more detailed description than the one in the Description
field (what is it, what can I use it for?).
Multiple lines allowed. Because this field will be displayed without
the benefit of word-wrap, you should manually insert line breaks in
order to keep lines less than 79 chars (if possible).
This is for information that is needed to use the package (how do
I use it?). As in "run wmaker.inst once before using WindowMaker".
Multiple lines allowed. Because this field will be displayed without
the benefit of word-wrap, you should manually insert line breaks in
order to keep lines less than 79 chars (if possible).
DescPackaging
Notes about the packaging. Stuff like "patches the Makefile to put
everything in place" goes here. Multiple lines allowed.
Notes that are specific to porting the package to Darwin. Stuff
like "config.guess and libtool scripts are updated, -no-cpp-precomp
is necessary" goes here. Multiple lines allowed.
Beginning with fink 0.9.9, a single .info file can be used to build
multiple packages.
The install phase begins as usual, with the execution of the
InstallScript and DocFiles commands.
A SplitOff or SplitOffN field, if present, then triggers the
creation of an
additional install directory.
Within the
SplitOff or Spli