3 ms·

>Include how the library gets in your build, not how you link it. Kind of depends. If you're in a Linux environment or something like MSYS, you'd just need the

>Include how the library gets in your build, not how you link it. Kind of depends. If you're in a Linux environment or something like MSYS, you'd just need the relevant Eigen package (in MSYS: mingw-w64-eigen3), which then you can link against. You could build it from source instead I suppose, and it has its own cmakelists which you just add as a subproject if you want to go that route. This isn't rocket science. Could it be easier? Sure. But it's not terrible either. >How can you make you changes to something you don't understand and make sure that it still works? Also, this is absolute nightmare from perspective of team and org cohesion. You learn about how the part you're modifying works. Ask for some assistance from the team members. Read the docs. Look up anything from libraries/stdlib that you don't understand, go into the debugger and watch as the state changes. Build the knowledge gradually. The next thing won't be as difficult. Don't try to take in the entire project at once, that's an overload of information for any non-trivial project. Again, that's true in literally any language.

fsloth 3y ago
It sounds like you are operating in an existing org with a mature codebase. In this context, where the existing product is implemented using C++, continuing to use the language makes perfect sense. I implement and maintain C++ for my day job so sure, it's not that bad ... it's only bad when you compare it to the state of the art in other language ecosystems. "This isn't rocket science. Could it be easier? Sure. But it's not terrible either." I don't know how to measure "terrible". I agree it's not rocket science. And it's much better than two decades ago. But still, compared almost to any other industrial language (which of course have their own set of problems) the default experience setting up and maintaining a cross platform project is abysmal. By "abysmal" I mean that defining the build is not a project goal in itself that requires meticulous design and expertise, and is something that just works out of the box. If you work only in posix land the experience is far less uncomfortable, of course.

fsloth 3y ago

It sounds like you are operating in an existing org with a mature codebase. In this context, where the existing product is implemented using C++, continuing to use the language makes perfect sense. I implement and maintain C++ for my day job so sure, it's not that bad ... it's only bad when you compare it to the state of the art in other language ecosystems. "This isn't rocket science. Could it be easier? Sure. But it's not terrible either." I don't know how to measure "terrible". I agree it's not rocket science. And it's much better than two decades ago. But still, compared almost to any other industrial language (which of course have their own set of problems) the default experience setting up and maintaining a cross platform project is abysmal. By "abysmal" I mean that defining the build is not a project goal in itself that requires meticulous design and expertise, and is something that just works out of the box. If you work only in posix land the experience is far less uncomfortable, of course.