From bcc17d1a53f41b5563cfac47380f7e4528b354cd Mon Sep 17 00:00:00 2001 From: Bennett Goble Date: Sun, 24 Mar 2024 16:23:19 -0700 Subject: [PATCH] Boost 1.84.0 --- .github/workflows/build.yaml | 17 +- .hgignore => .gitignore | 3 +- BuildParams | 7 - README.Linden | 403 ----------------------------------- README.md | 6 + autobuild.xml | 203 +++++++++--------- build-cmd.sh | 8 +- 7 files changed, 118 insertions(+), 529 deletions(-) rename .hgignore => .gitignore (53%) delete mode 100755 BuildParams delete mode 100644 README.Linden create mode 100644 README.md diff --git a/.github/workflows/build.yaml b/.github/workflows/build.yaml index 3f2a752..af25b60 100644 --- a/.github/workflows/build.yaml +++ b/.github/workflows/build.yaml @@ -1,25 +1,20 @@ name: Build -on: [push] +on: + pull_request: + push: + branches: [main] + tags: [v*] jobs: build: strategy: matrix: - os: [windows-2022, macos-11, ubuntu-22.04] - addrsize: ["64"] - include: - - os: windows-2022 - addrsize: "32" - continue-on-error: false + os: [windows-2022, macos-13, ubuntu-22.04] runs-on: ${{ matrix.os }} steps: - uses: secondlife/action-autobuild@v3 - with: - addrsize: ${{ matrix.addrsize }} release: needs: build runs-on: [ubuntu-latest] if: startsWith(github.ref, 'refs/tags/v') steps: - uses: secondlife/action-autobuild-release@v3 - with: - public: true diff --git a/.hgignore b/.gitignore similarity index 53% rename from .hgignore rename to .gitignore index cfa973e..c44bf72 100644 --- a/.hgignore +++ b/.gitignore @@ -1,3 +1,4 @@ -syntax glob stage/ build/ +.vs/ +x64/ diff --git a/BuildParams b/BuildParams deleted file mode 100755 index 9271d2d..0000000 --- a/BuildParams +++ /dev/null @@ -1,7 +0,0 @@ -PACKAGE_NAME = colladadom -public_build = true -build_legacy_package = false - -# Need viewer-build-variables as well as other shared repositories -buildscripts_shared_more_NAMEs="build_variables" -build_variables_repostory_url = "https://bitbucket.org/lindenlab/viewer-build-variables" diff --git a/README.Linden b/README.Linden deleted file mode 100644 index 4cbdab2..0000000 --- a/README.Linden +++ /dev/null @@ -1,403 +0,0 @@ - -0. Pre-Checkin Checklist - - Performed from top of repo, default branch, head: - - [ ] ... - - -1. Introduction - - Build of collada-dom library hosted on sourceforge.net. - - Repo structure does *not* follow the standard conventions (see - section at end). There's no 'vendor' branch and upstream - distributions and local modifications have been blended into the - same flow. It would be possible to synthesize a vendor branch at - the 2.3 revision and move forward with 2.4 and beyond. Haven't - done that for this effort. - - -2. Modifications - - 2.1 Historical (before 2014) - - Build of the 2.3 collada-dom distribution as shared libraries. - Libraries appear as a version 2.2 release but are actually 2.3. - Linden repo is essentially the 'dom' fragment from the full repo - plus a lot of build work. Source *appears* to be mostly identical - to distribution. - - 2.2 Library Refresh Project - - The three main evils to be corrected are: - - * The collada-dom shared libraries are re-exporting the interfaces - of other libraries. - - * These other libraries are out-of-date with the versions used in - other parts of the build but the collada-dom can still provide - symbol resolution. - - * These other libraries are supplied as magic binary blobs in the - distribution with no information on how they are built. - - The Linux library has been exporting boost::filesystem, pcrecpp, - libxml2, and possibly others: - - 00424970 T _ZN5boost10filesystem6detail10remove_allERKNS0_4pathEPNS_6system10error_codeE - 004292c0 T _ZN5boost10filesystem6detail11lex_compareENS0_4path8iteratorES3_S3_S3_ - 00420740 T _ZN5boost10filesystem6detail11permissionsERKNS0_4pathENS0_5permsEPNS_6system10error_codeE - ... - 0040aeaa T _ZN7pcrecpp3Arg15parse_ulonglongEPKciPv - 0040b562 T _ZN7pcrecpp3Arg16parse_int_cradixEPKciPv - 0040b484 T _ZN7pcrecpp3Arg16parse_long_octalEPKciPv - ... - 003a2350 T __xmlGlobalInitMutexDestroy - 003a2450 T __xmlGlobalInitMutexLock - 003a24a0 T __xmlGlobalInitMutexUnlock - - Mac has been exporting additional material: - - 00002460 T __ZN5boost6system12system_errorD0Ev - 0000ed40 T __ZN5boost6system12system_errorD1Ev - 0016e2c2 T __ZN5boost6system14error_categoryD0Ev - ... - 00176840 T _unzClose - 001767b0 T _unzCloseCurrentFile - 00176330 T _unzGetCurrentFileInfo - 001764b0 T _unzGetFilePos - - - So, the corrective actions taken to move away from this are as - follows: - - * Create a '_deprecated_' directory and 'hg mv' all libraries - other than 'tinyxml' in 'external-libs' to it. The 'tinyxml' - library is left as we don't use it in our code and it's harmless - as-is. - - * Create package dependencies on boost, pcre, libxml2 and zlib. - (Zlib also provides minizip now.) - - * Build modifications to Makefile, make/dom.mk, make/domTest.mk - and the VC10 project files to compile and link against the - package dependencies. For whatever reason, make/* is using - ccFlags/libOpts/includeOpts to control compilation while - Makefile is using CC/CXX/CFLAGS/CXXFLAGS, etc. There was no - communication between the two so common.mk was modified to - incorporate Makefile settings into make/*.mk processes. - - * Autobuild packaging of only the static archives. Shared - libraries are still built and they still have their undesireable - re-exports of other libraries. DO NOT PACKAGE THESE UNTIL THAT - IS ADDRESSED. - - -3. Source Origin - - 2.3: - http://sourceforge.net/projects/collada-dom/files/Collada%20DOM/Collada%20DOM%202.3/collada-dom-2.3.tgz/download - - -4. Package Contents - - Common: - * include/collada/* - - Windows: - * lib/release/libcollada14dom23-s.lib - * lib/debug/libcollada14dom23-sd.lib - - Mac OS X (debug and release): - * lib/release/libcollada14dom.a - * lib/debug/libcollada14dom-d.a - - Linux: - * lib/release/libcollada14dom.a - * lib/debug/libcollada14dom-d.a - - -5. Consumers/Dependents - - Consumers of shared collada-dom libraries must define DOM_DYNAMIC - in their compilations to get the correct declspec behavior. - Consumers using archives must not define this. - - Transitive dependencies, such as needing PCRE_STATIC, may result - as well. This likely means you've picked up internal headers that - should have been avoided. - - Packages dependent on colladadom which will need attention - (autobuild.xml) after changes. This is not authoritative, use - appropriate build tools to find all dependents. - - * viewer - - -=================================================================== - - Third-Party Library Repo Structure - - -Introduction - -We want to have a way to capture local modifications to a third-party -open-source project, such as libcurl, without needing write access to -their public repository. We want to be able to carry forward such -modifications to newer versions of the public project. All this -should be independent of the organizational decision as to whether -it's even desirable to try to submit our local modifications upstream. - -Fortunately, the Subversion folks articulated a process years ago that -addresses this very requirement. They call it "Vendor Branches." The -same tactic, suitably adapted, works with Mercurial too. - -The essence of the idea is that we capture and tag a particular -snapshot of the open-source project. We develop our local -modifications to that, and the repository tip incorporates them. But -when we want to update to a newer version of the public project, we -bring it into the repository in such a way that we can discover the -changes from the original snapshot and the new one -- and then have -Mercurial apply those deltas to the ''combined'' source. - -The following material is adapted from -http://svnbook.red-bean.com/en/1.1/ch07s05.html, the Red Bean -Subversion book, but recast for Mercurial. The Linden source for this -material is an internal wiki. There may be superceding documentation -on the public wiki when you read this. We recommend searching there -for updates to conventions below. And note that each particular -library may implement variations of this scheme. - - -General Vendor Branch Management Procedure - -Managing vendor branches generally works like this. You create a -named branch ("vendor") to store the vendor source snapshots. Then -you import the third party code into that branch. Your modified -branch (named "default") is based on "vendor". You always make your -local changes to the default branch. With each new release of the -code you are tracking you bring it into the "vendor" branch and merge -the changes into "default", resolving whatever conflicts occur between -your local changes and the upstream changes. - -Perhaps an example will help to clarify this algorithm. We'll use a -scenario where your development team is creating a calculator program -that links against a third-party complex number arithmetic library, -libcomplex. We'll construct a repository specifically for our -locally-modified version of that library. To begin, we must -initialize our repository and create at least one file in our -"default" branch. - - $ hg init ourcomplex - $ cd ourcomplex - $ touch README.txt - $ hg commit README.txt - -Now we can create the vendor branch and do the import of the first -vendor drop. We'll call our vendor branch "vendor", and each -successive code drop will be tagged "current". - - $ hg branch vendor - $ tar -xjf ../libcomplex-1.0.tar.bz2 - $ mv libcomplex-1.0 libcomplex - $ hg addremove - $ hg commit -m "1.0 source drop" - $ hg tag -r tip current - $ hg tag -r current 1.0 - -We now have the current version of the libcomplex source code in -branch "vendor", tagged "current" and in a non-version-specific source -code subdirectory ("libcomplex"). Next, we merge it into the default -branch. It is in the default branch that we will make our -customizations. - - $ hg update default - $ hg merge vendor - $ hg commit -m "initial: 1.0" - -We get to work customizing the libcomplex code. Before we know it, -our modified version of libcomplex is now completely integrated into -our calculator program. - -A few weeks later, the developers of libcomplex release a new version -of their library, version 1.1, which contains some features and -functionality that we really want. We'd like to upgrade to this new -version, but without losing the customizations we made to the existing -version. What we essentially would like to do is to replace our -current baseline version of libcomplex 1.0 with a copy of libcomplex -1.1, and then have Mercurial re-apply the custom modifications we -previously made to that library to the new version. But we actually -approach the problem from the other direction, applying the changes -made to libcomplex between versions 1.0 and 1.1 to our modified copy -of it. - -To perform this upgrade, we update our repository to our vendor -branch, and update the "current" tag with the new libcomplex 1.1 -source code. We quite literally replace the existing files with the -new files, clearing out the whole tree and exploding the libcomplex -1.1 release tarball in its place. The goal here is to make the tip of -our vendor branch contain only the libcomplex 1.1 code, and to ensure -that all that code is under version control. Oh, and we want to do -this with as little version control history disturbance as possible. - - $ hg update vendor - $ rm -rf * - $ tar -xjf ../libcomplex-1.1.tar.bz2 - $ mv libcomplex-1.1 libcomplex - $ hg addremove -s 60 - $ # Additional 'hg add' and 'hg rm' commands if needed - $ hg commit -m "1.1 source drop" - -After unpacking the 1.1 tarball, hg status will show files with local -modifications as well as, perhaps, some unversioned or missing files. -If we did what we were supposed to do, the unversioned files are only -those new files introduced in the 1.1 release of libcomplex. The -missing files are files that were in 1.0 but not in 1.1. The 'hg -addremove' command deals with both, and more: the '-s 60' switch -directs Mercurial to compare added files to deleted files, recognizing -any file at least 60% similar as a move/rename. - -For simple or stable libraries, the 'hg addremove' command should be -reliable. For more complicated libraries subject to refactoring or -large gaps of time between updates (e.g. libcurl), it can get a little -lost trying to match files in the old release with files in the new -release. Pay attention to the output of the command or better still, -do dry runs. Files erroneously moved can be excluded with the '-X' -option and then dealt with individually with 'hg add' and 'hg rm' -commands after 'hg addremove'. (The readme file in the curl library -should document a particularly challenging case.) - -The 'addremove' process doesn't have to be perfect. Recreating the -evolution of the upstream source tree isn't universally practical. -But we'd like to capture movement of files in the vendor branch that -are modified in the default branch. If achieving that becomes too -tedious, then re-implementation of the default branch edit in a new -file is fine. Just note it here for the next developer. - -Finally, once our current working copy contains only the libcomplex -1.1 code, we commit the changes we made to get it looking that way. - -Our current vendor branch now contains the new vendor drop. We move -the 'current' tag to the new version (in the same way we previously -tagged the version 1.0 vendor drop), and then merge the differences -between the version 1.0 and version 1.1 into our default branch. - - $ hg tag -f -r tip current - $ Optional: hg tag -r current 1.1 - $ hg update default - $ hg merge vendor - # resolve all the conflicts between their changes and our changes - # if you will have conflicts in .hgtags, simply take *all* lines - ... - $ hg commit -m "update with 1.1" - -Any additional work needed to get the merged library working can -now be done on the default branch. - - -Revision Tags - -We don't currently make use of Mercurial tags in the build and release -process for 3rd-party libraries. But we would like to establish a -convention to document update and release points. The tags we would -like to establish are: - - * 'current' Points to a succession of vendor releases checked into - the 'vendor' branch. Will almost always be at or close to branch - head. - - * '' Ttag on the 'vendor' branch pointing to a verbatim - checkin of a 3rd-party's release. Example: '7.21.1' for - a particular version of libcurl we have used. - - * Release-type tags on the default branch aren't as useful given how - Mercurial handles tags and how autobuild works. - - -Schematic of a Third-Party Repository - -Below is the output of the 'hg glog' command showing a library project -going through an initial 1.0 release and an update from the vendor to -1.1. Significant revisions in the repository lifecycle are as -follows: - - 0 Creation of the repo with an initial file. - 1 1.0 code drop on branch 'vendor' - 4 Merge of 1.0 code onto branch 'default' - 5 Modifications to library we wish to keep over time. Released. - 6 1.1 code drop on branch 'vendor' - 9 Merge of 1.1 code onto branch 'default' -10 Fixes to merge yielding production 1.1 library. Released. - - -@ changeset: 10:888229641f6e -| tag: tip -| user: Monty Brandenberg -| date: Wed Oct 30 13:35:51 2013 -0400 -| summary: Work to get 1.1 merge working. Release. -| -o changeset: 9:925ccdf09f50 -|\ parent: 5:83c5775c23dc -| | parent: 8:977001a08e48 -| | user: Monty Brandenberg -| | date: Wed Oct 30 13:35:20 2013 -0400 -| | summary: update with 1.1 -| | -| o changeset: 8:977001a08e48 -| | branch: vendor -| | user: Monty Brandenberg -| | date: Wed Oct 30 13:33:49 2013 -0400 -| | summary: Added tag 1.1 for changeset 5f6cb89add91 -| | -| o changeset: 7:59bce0f6d12f -| | branch: vendor -| | user: Monty Brandenberg -| | date: Wed Oct 30 13:33:41 2013 -0400 -| | summary: Added tag current for changeset 5f6cb89add91 -| | -| o changeset: 6:5f6cb89add91 -| | branch: vendor -| | tag: current -| | tag: 1.1 -| | parent: 3:8525ad934ecd -| | user: Monty Brandenberg -| | date: Wed Oct 30 13:33:29 2013 -0400 -| | summary: 1.1 source drop -| | -o | changeset: 5:83c5775c23dc -| | tag: 1.0 -| | user: Monty Brandenberg -| | date: Wed Oct 30 13:32:31 2013 -0400 -| | summary: Linden-specific changes to the library. Release -| | -o | changeset: 4:bccb736585f4 -|\| parent: 0:400e4516c406 -| | parent: 3:8525ad934ecd -| | user: Monty Brandenberg -| | date: Wed Oct 30 13:31:40 2013 -0400 -| | summary: initial: 1.0 -| | -| o changeset: 3:8525ad934ecd -| | branch: vendor -| | user: Monty Brandenberg -| | date: Wed Oct 30 13:30:21 2013 -0400 -| | summary: Added tag 1.0 for changeset 8ac3828d03bb -| | -| o changeset: 2:7aa1a1cb62d9 -| | branch: vendor -| | user: Monty Brandenberg -| | date: Wed Oct 30 13:30:14 2013 -0400 -| | summary: Added tag current for changeset 8ac3828d03bb -| | -| o changeset: 1:8ac3828d03bb -|/ branch: vendor -| tag: 1.0 -| user: Monty Brandenberg -| date: Wed Oct 30 13:30:09 2013 -0400 -| summary: 1.0 source drop -| -o changeset: 0:400e4516c406 - user: Monty Brandenberg - date: Wed Oct 30 13:29:16 2013 -0400 - summary: Created repo with initial readme file diff --git a/README.md b/README.md new file mode 100644 index 0000000..261cbfa --- /dev/null +++ b/README.md @@ -0,0 +1,6 @@ +# 3p-colladadom + +[Autobuild][] packaged [colladadom][]. + +[Autobuild]: https://github.com/secondlife/autobuild +[colladadom]: https://www.khronos.org/collada/wiki/Portal:COLLADA_DOM \ No newline at end of file diff --git a/autobuild.xml b/autobuild.xml index 278818a..4bbe6c3 100755 --- a/autobuild.xml +++ b/autobuild.xml @@ -1,14 +1,19 @@ - - - version - 1.3 - type - autobuild + installables boost + copyright + (see individual source files) + description + Boost C++ Libraries + license + boost 1.0 + license_file + LICENSES/boost.txt + name + boost platforms darwin64 @@ -16,11 +21,11 @@ archive hash - 8539775e0a0783bd252bc548b20b3472a8254c31 + d8d9e1e15ec09c81acfa9ffb80c3f20435373543 hash_algorithm sha1 url - https://github.com/secondlife/3p-boost/releases/download/v1.81-09d25a7/boost-1.81-darwin64-09d25a7.tar.zst + https://github.com/secondlife/3p-boost/releases/download/v1.84.0-r1/boost-1.84-darwin64-8499892512.tar.zst name darwin64 @@ -30,11 +35,11 @@ archive hash - a3bfbdba7e1977e7e65266ec654990bb13994bd3 + a5552fcd343179c4c7d6dd6289675431a8c0fe8d hash_algorithm sha1 url - https://github.com/secondlife/3p-boost/releases/download/v1.81-3d0d7fc/boost-1.81-linux64-3d0d7fc.tar.zst + https://github.com/secondlife/3p-boost/releases/download/v1.84.0-r1/boost-1.84-linux64-8499892512.tar.zst name linux64 @@ -58,31 +63,31 @@ archive hash - d40c86fbcb6ce064d546165cbabbf035ea80e07b + 5af9c69093e171eda552720a7acd570496db17db hash_algorithm sha1 url - https://github.com/secondlife/3p-boost/releases/download/v1.81-09d25a7/boost-1.81-windows64-09d25a7.tar.zst + https://github.com/secondlife/3p-boost/releases/download/v1.84.0-r1/boost-1.84-windows64-8499892512.tar.zst name windows64 - license - boost 1.0 - license_file - LICENSES/boost.txt - copyright - (see individual source files) version - 1.81 - name - boost - description - Boost C++ Libraries + 1.84 libxml2 + copyright + Copyright (C) 1998-2012 Daniel Veillard. All Rights Reserved. + description + Libxml2 is the XML C parser and toolkit developed for the Gnome project. + license + mit + license_file + LICENSES/libxml2.txt + name + libxml2 platforms darwin64 @@ -142,21 +147,23 @@ windows64 - license - mit - license_file - LICENSES/libxml2.txt - copyright - Copyright (C) 1998-2012 Daniel Veillard. All Rights Reserved. version 2.9.4.2db4418 - name - libxml2 - description - Libxml2 is the XML C parser and toolkit developed for the Gnome project. minizip-ng + canonical_repo + https://bitbucket.org/lindenlab/3p-minizip-ng + copyright + This project uses the zlib license. Copyright (C) 1995-2013 Jean-loup Gailly and Mark Adler + description + minizip-ng is a zip manipulation library. Based on work of Gilles Vollant. + license + minizip-ng + license_file + LICENSES/minizip-ng.txt + name + minizip-ng platforms darwin64 @@ -216,23 +223,21 @@ windows64 - license - minizip-ng - license_file - LICENSES/minizip-ng.txt - copyright - This project uses the zlib license. Copyright (C) 1995-2013 Jean-loup Gailly and Mark Adler version 3.0.2.3e9876e - name - minizip-ng - canonical_repo - https://bitbucket.org/lindenlab/3p-minizip-ng - description - minizip-ng is a zip manipulation library. Based on work of Gilles Vollant. pcre + copyright + Copyright (c) 1997-2014 University of Cambridge; Copyright(c) 2009-2014 Zoltan Herczeg; Copyright (c) 2007-2012, Google Inc. + description + PCRE Perl-compatible regular expression library + license + bsd + license_file + LICENSES/pcre-license.txt + name + pcre platforms darwin64 @@ -292,21 +297,23 @@ windows64 - license - bsd - license_file - LICENSES/pcre-license.txt - copyright - Copyright (c) 1997-2014 University of Cambridge; Copyright(c) 2009-2014 Zoltan Herczeg; Copyright (c) 2007-2012, Google Inc. version 8.35.3c0eb51 - name - pcre - description - PCRE Perl-compatible regular expression library zlib-ng + canonical_repo + https://bitbucket.org/lindenlab/3p-zlib-ng + copyright + Copyright (C) 1995-2013 Jean-loup Gailly and Mark Adler + description + zlib data compression library for the next generation systems + license + zlib-ng + license_file + LICENSES/zlib-ng.txt + name + zlib-ng platforms darwin64 @@ -366,27 +373,25 @@ windows64 - license - zlib-ng - license_file - LICENSES/zlib-ng.txt - copyright - Copyright (C) 1995-2013 Jean-loup Gailly and Mark Adler version 1.2.11.zlib-ng.32fd361 - name - zlib-ng - canonical_repo - https://bitbucket.org/lindenlab/3p-zlib-ng - description - zlib data compression library for the next generation systems package_description + canonical_repo + https://github.com/secondlife/3p-colladadom + copyright + Copyright 2006 Sony Computer Entertainment Inc. + license + SCEA + license_file + LICENSES/collada.txt + name + colladadom platforms - + common @@ -402,7 +407,7 @@ options ../build-cmd.sh - + name RelWithDebInfo @@ -412,25 +417,26 @@ include/collada LICENSES/*.txt - docs/colladadom/README.Linden - + name common darwin + build_directory + stage configurations RelWithDebInfo build - command - bash arguments build-cmd.sh - + + command + bash default true @@ -441,26 +447,26 @@ manifest lib/release/*.a - - build_directory - stage + name darwin linux + build_directory + stage configurations RelWithDebInfo build - command - bash arguments build-cmd.sh - + + command + bash default true @@ -471,26 +477,26 @@ manifest lib/release/*.a - - build_directory - stage + name linux windows + build_directory + stage configurations RelWithDebInfo build - command - bash arguments build-cmd.sh - + + command + bash default true @@ -501,27 +507,18 @@ manifest lib/release/*-s.lib - - build_directory - stage + name windows - license - SCEA - license_file - LICENSES/collada.txt - copyright - Copyright 2006 Sony Computer Entertainment Inc. - version_file - VERSION.txt - name - colladadom - canonical_repo - https://github.com/secondlife/3p-colladadom source_directory . + version_file + VERSION.txt - - \ No newline at end of file + type + autobuild + version + 1.3 + diff --git a/build-cmd.sh b/build-cmd.sh index ea76db0..7e599e8 100755 --- a/build-cmd.sh +++ b/build-cmd.sh @@ -113,6 +113,8 @@ case "$AUTOBUILD_PLATFORM" in opts="${TARGET_OPTS:--arch $AUTOBUILD_CONFIGURE_ARCH $LL_BUILD_RELEASE}" + nproc=$(sysctl -n hw.physicalcpu) + libdir="$top/stage" mkdir -p "$libdir"/lib/release @@ -121,6 +123,7 @@ case "$AUTOBUILD_PLATFORM" in # Without the -Wno-etc flag, incredible spam is produced make \ conf=release \ + -j$nproc \ CFLAGS="$opts" \ CXXFLAGS="$opts -Wno-unused-local-typedef" \ LDFLAGS="-Wl,-headerpad_max_install_names" \ @@ -158,7 +161,7 @@ case "$AUTOBUILD_PLATFORM" in make clean arch="$AUTOBUILD_CONFIGURE_ARCH" # Hide 'arch' env var - make -j6 \ + make -j$(nproc) \ conf=release \ LDFLAGS="$opts" \ CFLAGS="$opts" \ @@ -182,6 +185,3 @@ cp -a license.txt stage/LICENSES/collada.txt ## mkdir -p stage/LICENSES/collada-other cp -a license/tinyxml-license.txt stage/LICENSES/tinyxml.txt - -mkdir -p stage/docs/colladadom/ -cp -a README.Linden stage/docs/colladadom/