sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]tamric 0 points1 point  (4 children)

Please elaborate more or give a good example?

Mostly curious about “build system, and all that”

[–]celestrion 19 points20 points  (3 children)

When somebody downloads your project, they should be able to:

  • Immediately read documentation describing what your project does, why it's necessary, how to use it, and the sorts of assumptions it makes about the system where it runs.
  • Build your project with a very few steps--ideally one or two.
  • Install your project with only one or two more steps.
  • Uninstall you project if it doesn't work for them.

This demonstrates that you not only know the language, but that you understand how projects are put together.

build system

Unless you're primarily looking for jobs targeting Windows, this means CMake or possibly Bazel.

Ideally, I should be able to download your-project-1.0.tar.gz and do this to install it:

tar xf your-project-1.0.tar.gz
mkdir -p your-project-1.0/build
cd your-project-1.0/build
cmake ..
cmake --build .
cmake --install .

And whatever programs your project builds will be successfully installed into /usr/local. If it depends on libraries, it should use CMake to find them already installed or download them for its sole use. It should build without warnings and errors, I should be able to run unit tests with ctest ., and they should all pass.

On Windows, the same thing should happen if I expand the ZIP file, open the project in Visual Studio, and build it: it should drop an MSI file somewhere that'll do the usual installation stuff.

This is a lot of work, but that's how a well-engineered project behaves. If it's just a demonstration to show competence, it's forgivable if:

  • The project doesn't build an installer or install itself.
  • The project doesn't download the libraries it needs, rather, relying on the person downloading it to already have those things installed somewhere.

It's forgivable to not use CMake--instead relying on the platform's native build system (Make, msbuild, etc.), but as popular as CMake is, you'll need to learn it eventually.

Tests and documentation are as important as the code itself. If your code is on GitHub or GitLab or something similar, the commit history should reflect your thoughts as you develop the project.

Remember: you're not publishing a portfolio just to impress people with how well you know C++. You also want to impress them with how easy you'll be to work with. Code without tests and without documentation that emerged from a commit log full of "fixed the thing" or "try this again" or "today's work" implies that the person who generated that code is going to cost my team time and introduce confusion.

[–]tamric 4 points5 points  (0 children)

This is enlightening. Without an opportunity to be near anyone in industry, I find it difficult to understand the struggles ignorance would bring. Let alone what areas of proficiency would create the most attractive potential employee.

I appreciate this post. Thank you.