A buildpack for deploying CppCMS applications.
Your application must have a config file in its root directory named
cppcms.js. This file is where the buildpack will inject environment
configuration, such as the listen port.
You must provide a
Makefile whose default target will compile the
cppcms executable referenced by your start command.
Finally, the default start command will be
make run, meaning that
the buildpack expects there to be a
run target. If you prefer, you
may provide a custom start command, either through
an application manifest
or on the
cf push commandline.
The CppCMS headers and libraries will be available at the
subdirectory, so a working command might look like:
hello: c++ hello.cpp -o hello -Lcppcms/lib -Icppcms/include -lcppcms -lbooster -lz
default: hello run: ./hello -c cppcms.js hello: hello.cpp c++ hello.cpp -o hello -Lcppcms/lib -Icppcms/include -lcppcms -lbooster -lz clean: rm -f hello
There's a "hello world" app in
test/fixtures/hello-world that you can deploy by using the command:
cf push appname -b https://github.com/cloudfoundry-community/cppcms-buildpack
static versus shared linking
currently the cppcms tarball contains both shared and static libraries. it shouldn't.
we may also want to figure out how to do static linking, but this page indicates it may not actually be easy or desirable.
should config.js get handled in the default start command?
currently we're doing it in
Copyright 2016, Mike Dalessio
The buildpack is released under the Apache 2.0 license, see
LICENSE for for the full text.
I am not a lawyer, and so have no idea if the previous two statements are compatible with each other. Let me know if you have thoughts.