linux build instructions need improvement

[wizfromoz]

I'm trying to build CxxProf on a customized SuSE Linux. The requirement is that I build everything from sources, so I can't use prebuilt binary packages.

One of the 3rd party components that CxxProf depends on, Plume, has no build instructions and no contact information to ask questions. It has a sample, contributed, build, but this is for 64 bit architecture that I don't have.

I built other 3rd party packages that are needed, but I don't know exactly how and where to set their locations so that build.py script would work. I read documentation several times, and had a look at various scripts, but I just can't figure it out.

Ideally, 3rd party packages should be built alongside CxxProf. The users should just download sources (if you have distribution limitations), set locations of these sources in some build preparation step and start building.

I've spent about 6 hours so far on this. Ideally, it should be fairly quick, get sources, configure, make, make install.

[monsdar]

The info you're searching is hidden in the DevGuide - Use your own Thirdparty chapter. I must admit that it's not very verbose.

You have to create a setEnv.cmake which is located in the thirdparty directory. Withing this file are all the pathes of libraries etc set. The CMakeLists.txt of all the components use setEnv.cmake at build-time to find their thirdparty. This solution allows to easily integrate custom thirdparty and deliver a selfcontained environment.

Pluma provides a release with a Makefile included in their Download area. This is what I used when I created the Linux-based Thirdparty.

The concept of the CxxProf build-system is to provide prebuilt thirdparty to get the user going as easy/fast as possible. It however is possible to build the thirdparty by yourself and it is a good idea to provide a script alongside the thirdparty packages which automates the building of the specific components.

[wizfromoz]

I'll be playing with all this today, but it would be good, especially for those not familiar with cmake (like me), to explain what the expected source file directory layout is. After looking through scripts, it seems that 'thirdparty' directory is expected to exist on the same level as 'src' of the main distro, for build to work.

In the example setEnv.cmake file for thirdparty, I'm not sure what sets Boost_FOUND variable. I have boost installed on the system, which I'd like to use. It's not clear to me what various settings for the boost are about.

[wizfromoz]

Ok, a few more points. build.py requires multiprocessing module, which doesn't come in SuSE distro. I installed it, tried again. Now I get "No cmake executable found, please check your Thirdparty" even though I do have cmake on the system. So, I tried running with --native-cmake, but got the same error again. Then I manually set CMAKE_EXE to where cmake is on my system and - it started running! ... but not for long :-)

I'll push a bit more, when I have some more info, will provide feedback

[monsdar]

Yes, the thirdparty directory needs to be placed along with the src directory.

In relation to the setEnv.cmake from the gcc32 repo:

• Change the BOOST_ROOT in L46 to the directory where your Boost is installed. If that does not work try to comment it out with an #. CMake then should search in System pathes. Hope that works as I expect, I'm currently writing it out of my head.
• Change the include pathes and library destinations for the other Thirdparty in L57-58, L62-63, L67-68, L72-73.

If everything works as expected it shouldn't be necessary to know a lot about CMake at all. But you can never know how the users systems are built, that's why CxxProf is providing its own precompiled Thirdparty. It's better to have an environment where everything is included. I understand that it's not possible to use precompiled binaries in every situation :/

The best thing for the Linux-integration would be to have someone creating rpm/deb packages which could be targeted at different distros and thus solving all the dependency-stuff.

Note: I started writing the above before your last comment came in.

The --native-cmake flag does nothing else but using the system-wide cmake command to call cmake. Probably it wasn't available on your system. I only tested at Debian/Ubuntu distributions which differ in some parts from Suse.

I'm sorry that it's such a mess for you to get through the Thirdparty-stuff... It's one thing I truly hate with C++: Before you can get to work you usually have to work through a jungle of setting up dependencies and build systems. On the other side it's hard as a developer to provide build systems which work on a variety of different systems.

[wizfromoz]

Ok, I'm making some progress, but not quite. I got:

| We're building the following components in this iteration:

| -- cxxprof_static

| ...cxxprof_static - cmake - SUCCESS

| ...cxxprof_static - release - ~~ ERROR: 2 ~~

Errors occured, stopping the build...

What does it mean? What did I succeed in and where I failed? How do I debug this? I was stepping through build.py, but you use multithreading in the script so once the control is in threads, not sure where to put the breakpoint.

[monsdar]

The output in your case is written to build\cxxprof_static\build_cxxprof_static_release_out.log. It would probably be good if the error message at the end says that. I'll create an issue for that.

[wizfromoz]

Is there a way of specifying boost include and library paths, like for other 3rd party components? It seems that Cmake finds one version of boost, which is NOT the one I want to use, and then I get build errors, like "cannot find -lboost_thread-mt".

What exactly needs to be set for boost for build to work? You have, in setEnv.cmake:

IF(NOT Boost_FOUND)
various sets, followed by "find_package"

I know the intention was to provide smooth build on various systems, but ...

[monsdar]

Cxxprof is using the FindBoost.cmake functionality provided by CMake there. As in the docs you should be able to provide alternate search directories via BOOST_ROOT, BOOST_INCLUDEDIR and BOOST_LIBRARYDIR. By setting Boost_NO_SYSTEM_PATHS you define that the script does not fall back onto the default installation.

You can just define these attributes like the others after Boost_FOUND. There should be an alternative BOOST_ROOT already defined (which you commented out at first).

Note that these variables are case-sensitive and mixed up with BOOST_... and Boost_....

[monsdar]

Hey @wizfromoz, has it finally worked for you or have you given up?

[wizfromoz]

I haven't given up. It's still a high priority. However, in our specific environment (custom Linux), I have to upgrade the toolchain, primarily gcc compiler, in order to build Boost 1.55.0, that CxxProf needs, and that turned out to be a sizeable task. I'm still doing that, but getting closer to completion. As soon as that's over, I'm back at CxxProf.