Tiny but powerful single file wavefront obj loader written in C++03
Usage
Make sure to add the stable section of the cppget.org
repository to your project's repositories.manifest
to be able to fetch this package.
:
role: prerequisite
location: https://pkg.cppget.org/1/beta
# trust: ...
If the beta section of cppget.org
is not an option then add this Git repository itself instead as a prerequisite.
:
role: prerequisite
location: https://github.com/build2-packaging/tinyobjloader.git
Add the respective dependency in your project's manifest
file to make the package available for import.
depends: libtinyobjloader ^ 2.0.0-
The library can be imported by the following declaration in a buildfile
.
import tinyobjloader = libtinyobjloader%lib{tinyobjloader}
Configuration
There are no configuration options available.
Issues and Notes
- The precompiled library provided by the original build system is not accessible through this package. While a precompiled version would naively enhance the ease of use for the package consumers, the following reasons speak against it. First, the implementation of the header-only library is configurable and, as a result, we would either need to offer a precompiled library for each possible configuration or add as many configuration variables to the build system. The latter approach drastically complicates the reasoning about
buildfile
s and also the package's consumption in externmanifest
files. Furthermore, it would only allow for one single implementation configuration for each package that consumes the library. The former approach doesn't suffer from these properties and, as a matter of fact, is totally preferable. However, the process of defining library targets for each possible configuration is neither scalable (already trying to find an intuitive naming scheme may be impossible) nor testable. Second,tinyobjloader
is only tested and documented as single-header-only library and users will probably rely on the header-only variant anyway. - For now, examples are not compiled and run by the package's build system as they depend on GLFW and, as a consequence, would restrict our capabilities for testing certain target configurations on the CI server. This might be resolvable as soon as the restriction of test packages does not influence the restriction of their library package when running tests on the CI server.
- Currently, robust triangulation via Mapbox's Earcut is not supported. We need to find a way to handle this kind of in-place dependency that still might be resolved by the system or the user itself.
- The optimized loader is not supported by this package as it is still ranked experimental and no further tests are provided for it. Also, for Unix-based systems, it depends on
pthread
. Probably the package consumer would need to add this dependency by him-/herself. - Test fuzzers are not compiled and run.
- The library does not seem to support Emscripten.
Contributing
Thanks in advance for your help and contribution to keep this package up-to-date. For now, please, file an issue on GitHub for everything that is not described below.
Recommend Updating Version
Please, file an issue on GitHub with the new recommended version.
Update Version by Pull Request
- Fork the repository on GitHub and clone it to your local machine.
- Run
git submodule init
andgit submodule update
to get the current upstream directory. - Inside the
upstream
directory, checkout the new library versionX.Y.Z
by callinggit checkout vX.Y.Z
that you want to be packaged. Here, it is probably not a version but the newest commit from the master branch instead. - If needed, change source files,
buildfiles
, and symbolic links accordingly to create a working build2 package. Make sure not to directly depend on the upstream directory inside the build system but use symbolic links instead. - Update library version in
manifest
file if it has changed or add package update by using+n
for then
-th update. - Make an appropriate commit message by using imperative mood and a capital letter at the start and push the new commit to the
master
branch. - Run
bdep ci
and test for errors. - If everything works fine, make a pull request on GitHub and write down the
bdep ci
link to your CI tests. - After a successful pull request, we will run the appropriate commands to publish a new package version.
Update Version Directly if You Have Permissions
- Inside the
upstream
directory, checkout the new library versionX.Y.Z
by callinggit checkout vX.Y.Z
that you want to be packaged. Here, it is probably not a version but the newest commit from the master branch instead. - If needed, change source files,
buildfiles
, and symbolic links accordingly to create a working build2 package. Make sure not to directly depend on the upstream directory inside the build system but use symbolic links instead. - Update library version in
manifest
file if it has changed or add package update by using+n
for then
-th update. - Make an appropriate commit message by using imperative mood and a capital letter at the start and push the new commit to the
master
branch. - Run
bdep ci
and test for errors and warnings. - When successful, run
bdep release --tag --push
to push new tag version to repository. - Run
bdep publish
to publish the package to cppget.org.
license | MIT |
---|---|
project | tinyobjloader |
url | github.com/tinyobjloader/tinyobjloader |
doc-url | github.com/tinyobjloader/tinyobjloader |
src-url | github.com/tinyobjloader/tinyobjloader |
syoyo@lighttransport.com |
1 Version
version | 2.0.0-b.10+1 (2.0.0-rc.10 ; Version from 'upstream/CMakeLists.txt') |
---|---|
repository | https://pkg.cppget.org/1/beta |
depends | 0 |
reviews | +1 |