The vision and philosophy behind tipi.build implementation for native C and C++ developerswritten by @daminetreg // June 14, 2021
Easing C++ development, inciting code reuse and improving application end-users experience by speeding up software builds.
This is the core principle behind tipi.build, any line of code written for a product development, might at some point be reused.
If the opportunity happens, then it should succeed. Therefore each project is considered as a set of end-user entrypoints ( executables ) and developers entrypoint ( libraries ).
Reusing code with tipi.build is easy :
- Each project is a library, just include what you need from your former work.
- Refactor easily previous application utils code into libraries.
- No more any git submodule mess: keep easily up-to-date by letting tipi.build pull the latest version of your dependencies on each build.
Releasing software is hard, especially if you depend on other libraries and you need to ship them with. tipi.build builds statically links all your dependency by default and take care of shipping all what your user will need in your release bundle.
With our first-class WebAssembly support you can even ship binaries that run everywhere: browser, desktop, embedded...
Usually pulling a dependency means pulling a full chain of transitive dependencies.
tipi's goal is to offer the finest-granularity over traditional packages:
Don't pay for what you don't use.
Is a well-known C++ philosophy, but until tipi.build it did not materialize in package management.
Indeed a package is per-se full of things you just don't need now. That's why we worked hard on our algorithm with a touch of AI to allow building only what is used in the final application.
With the nimbleness you can declare a dependency ( i.e. actually we scan your
#includes ), you don't need to have a full package of unneeded things, just what you need.
Coding & Reusing others code is hard when you are on your own to setup compilers, build systems & version management. Sure there are Docker's, but they don't support every platform, sure there are Virtual Machines, but you need to log into them in an uncomfortable and it reduces the actual computer speed.
We solve this.
We deliver you virtual images of environments for any platform, that you can either mount into your host OS or run at incredible speed on tipi.build instances.
The issue with the cloud and online IDEs is that they are not usable on-the-go, when commuting or on slow connection.
Our tipi.build cloud is decentral, it provides every developer machine an extension of their core count and RAM count.
Files are synchronized on our build runners and build artifacts are sent back to the developer machines. That means tipi takes care of building and let the computer free for a great edition experience.
make -j 1024 to build or run tests on 1024 cores is just a matter of being logged into tipi.
As you can build on each keystrokes in our cloud (tipi will only build if syntactically the code is correct), you get a constant stream of new binary that can easily be hot-reloaded while you develop.
C and C++ with template metaprograms, preprocessor heavy builds and so on is really slow to build even on the best developer's machine.
tipi.build's algorithm is capable to determine which function, type, class or template is used by which other part of the code, hence instead of building slowly even in parallel (e.g. file by file), tipi can make any compiler compile the code at a finer granularity by driving it smartly.
The meta model behind tipi, can even reuse part of build caches for the part that didn't change.
tipi.build is opensource, and everything our users can do on our cloud, they can do it on-premise or on their single machine without any internet connection. We are developers and we love tools that enables us and don't get in our way. The same applies for tipi.
tipi.build founder and CEO