As mentioned before, library packages contain more knowledge than a simple .lcf. For Archicad to read this additional data, we have .info files that define them.

package.info

This is the most essential file for a library package. It contains basic data about the package in XML format.

The format of the package.info file has to be the following:

<?xml version="1.0" encoding="UTF-8"?>
<Package displayName="Name displayed in Archicad" packageID="GUID of package" buildID="00000000-0000-0000-0000-000000000000" version="1" subversion="1" requiredACVersion="28" requiredACBuildNum= "1">
	<LCFPath checksum="00000000000000000000000000000000" lcfPath="Filename of lcf.lcf"/>
	<Dependencies>
		<Dependency displayName="Dependency package name" packageID="GUID of dependency package" minSubVersion="0"/>
	</Dependencies>
	<LocDataPath>localizationData.info</LocDataPath>
</Package>

Some attributes are self-explanatory, but let us go over them in detail.

Package displayName

This is the name you will see in Archicad.

packageID

This is the unique identifier (GUID) of a package. Different subversions of the same package have the same packageID; however, a different (main)version requires a new packageID as well.

buildID

A unique identifier of the package, generated during build. Different builds of the same package result in different buildIDs.

version

Version numbering of the library package, usually starting with 0 or 1 as the first version. When you increase the version number, you should also generate a new packageID (the package name and version is the user-side equivalent of the packageID).

subversion

Subversion of the library version, usually starting with 0.

requiredACVersion

The minimum version of Archicad required to use the library package is 28 since library packages were introduced in that version. It is increased when the library package uses a new GDL feature that was unavailable in previous Archicad versions (such as a new library command, parameter type, library global, tool, library compatibility setting, etc.).

requiredACBuildNum

The minimum required Archicad build number to open the library package.

checksum

It is currently not used, but it can help identify different states of the .lcf files packed in the library package.

lcfpath

This is the path of the .lcf file packed into the .libpack, created during the build process. Usually, it is the package name with the .lcf extension.

Dependencies

The list of other library package(s) your library package relies on. If any of the library parts in your package uses any macros, subtypes or images from any other library packages, you have to list them here, otherwise it can not be guaranteed that all required packages will be loaded into Archicad. This part can be omitted if you do not have any dependency packages. All dependency packages need to be referenced using three identifiers:

displayName

The name of the dependency package, given to it in its own package.info file. This name is displayed in the Library Loading Report if the dependency is missing.

packageID

The unique identifier (GUID) of a package, given in the dependency package’s own package.info file.

minSubVersion

The minimum subversion of the dependency package, required for the library package. The packageID (which changes for each .libpack version) and the minSubVersion describes a needed exact minimum state of a library package).

LocDataPath

Reference to the localizationData.info file if you have one. Read more on this file below. If you don’t have a localizationData.info file, remove this tag altogether.

localizationData.info

The file referenced in package.info under LocDataPath contains important data about your package so that you can have more than one localization. You can change this during Archicad runtime, see Changing libpack Language of the User Documentation.

This file is only mandatory if you have referenced it in package.info. However, the most important feature of .libpacks is its multi-language aspect, so we recommend using it to get the most out of your library packages.

The localizationData.info file is in XML format and looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<LocalizationData>
    <MappingDefinitions>mappingDefinitions.json</MappingDefinitions>
    <PathNameTables>
        <PathNameTable language="INT" path="Localization/pathNameTableINT.json"/>
    </PathNameTables>
    <MappingValueTables></MappingValueTables>
    <Dictionaries>
        <Dictionary language="INT" type="fileName" path="Localization/Dictionaries/fileNamesINT.po"/>
        <Dictionary language="INT" type="folderName" path="Localization/Dictionaries/folderNamesINT.po"/>
        <Dictionary language="INT" type="symbolStrings" path="Localization/Dictionaries/symbolStringsINT.po"/>
    </Dictionaries>
</LocalizationData>

MappingDefinitions

Reference to the mappingDefinitions.json file, created in Creating parammapping.xml and MappingDefinitions.json.

If you have no parammapping.xml files in your objects, you should leave them empty.

PathNameTables

Reference to the pathnametable files of each localization in your libpack. One pathnametable file can be referenced for more languages, but not vice versa. If you have no pathnametable files in your libpack, you should leave this empty.

You can read more about pathnametables, their purpose, and their format in Creating pathNameTable.json.

<PathNameTable language="INT" path="Localization/pathNameTableINT.json"/>
<PathNameTable language="GER" path="Localization/pathNameTableINT.json"/>
<PathNameTable language="SWE" path="Localization/pathNameTableSWE.json"/>

In this example, if the Library Localization Preferences (see in Changing .libpack Language of the User Documentation) is set to have INT or GER as the top priority, the pathNameTableINT.json file will take effect. In contrast, SWE, as the top priority, uses pathNameTableSWE.json instead. If any other loc code is set as the top priority, Archicad moves on to the next loc code until one of the versions listed in the localizationData.info file is found. If none of them is found, the first value in the localizationData.info’s list takes effect.

MappingValueTables

This tag became redundant (and does not work), as MappingValueTables are shipped with template files instead of being part of the library package itself.

Dictionaries

Reference to the dictionary files of each language in your library package. One file can be referenced in more than one language.

You can read more about dictionary files, their types, and format in Creating symbolStrings.po and Creating fileNames.po and folderNames.po.

Matching the applied dictionaries to the selected language version works the same way as for PathNameTables.

If you have no dictionary files in your libpack, you can omit this part.