Compiling TBB is missing "make install".

[bluequartz]

I am trying to compile TBB 4.1 Update 1 on OS X 10.8.2 and there does not seem to be a "make install", just "make" How do I get an installation similar to what the precompiled binaries distribution has? Include, lib, bin?

 When I compile I get a subdirectory created "macos_intel64_gcc_cc4.2.1_os10.8.2_release" and the libraries inside of that.

The precompile binaries are useless because they link against the clik library which is not standard on OS X. What is it any ways?

Any help is appreciated.

Thanks

Mike Jackson

[Vladimir_P_1234567890]

hello Mike, in the macos_intel64_gcc_cc4.2.1_os10.8.2_release folder there should be tbbvars.sh and tbbvars.csh so you can source them and setup environment to build and run your code. --Vladimir

[Jaak_Ristioja__Cyber]

Vladimir Polin (Intel) wrote:

hello Mike,

in the macos_intel64_gcc_cc4.2.1_os10.8.2_release folder there should be tbbvars.sh and tbbvars.csh so you can source them and setup environment to build and run your code.

--Vladimir

It were much appreciated by many if TBB made it possible to "make install" itself to some given prefix. Currently it's very messy. Just take a look at what Gentoo has to do to properly install TBB (dev-cpp/tbb) system-wide. The same goes for projects that need to install TBB automatically to some prefix folder to use those for building other software. In all cases packagers and developers need to write custom scripts to install TBB properly, because TBB itself provides no means for this.

Additionally, even if installed system-wide or in a prefix, it were useful if TBB would install some <prefix>/lib/pkgconfig/tbb.pc (pkg-config) or <prefix>/lib/TBB/TBBConfig(Version)?.cmake (CMake) files so that other projects can just do stuff like "pkg-config --ldflags" (for pkg-config/autotools) or "FIND_PACKAGE(TBB 4.2 REQUIRED)" (in CMake) to retrieve all the necessary information they need to use TBB, e.g. required include directories, library names, library directories, other compiler flags, other linker flags etc.

All this would make it much easier to use TBB, especially in automated build scripts (e.g. using the ExternalProject module in CMake) and continuous integration systems. Just sourcing the shell script files might be enough for some, but is not a good option for all.

Best regards,

Jaak

[Anton_M_Intel]

Please consider submitting a contribution https://www.threadingbuildingblocks.org/submit-contribution

[Jaak_Ristioja__Cyber]

Anton Malakhov (Intel) wrote:
Please consider submitting a contribution https://www.threadingbuildingblocks.org/submit-contribution

I can't access that because I'm still waiting for Intel Support to fix login at the URL you mentioned.

However, given my time constraints I think that it's easier for me to just write another 20-line script (alike src_install() in the Gentoo ebuild) to deal with installation of TBB for our project, than to fix TBB's custom Makefile only based build system I know nothing of. Sorry.

PS: For extra synergy, have you considered publishing the TBB code repositories in public so people could submit code merge requests?

[bluequartz]

My vote is for TBB to adopt the CMake build system then they don't have to worry about shipping 3 different visual studio solutions and Makefiles and have NO installation capability. It would be much nice to just use CMake to build TBB. With that you get the ability to support lots of different IDEs or plain makefiles for those who would like to contribute. You also get packaging support for many different types of distributions from NSIS to Zip to shell to tar.gz to .dmgs. This also gives TBB the ability to add in additional package files to the installation to make integrating with other build systems and other projects much simpler and straight forward.

From my point of view looking in from the outside, TBB may be "open-source" but the barrier to entry is so high for a developer coming from the outside that it just is not worth the cost of time to try to figure out how to add anything to TBB. This is another reason why I don't update my TBB installations. The time to do so should be minimal.

I will give kudos to the TBB team for releasing lots of variations of the libraries for the Visual Studio platforms. These releases have saved me from trying to build TBB myself.

Mike Jackson (dream3d.bluequartz.net)

[bp]

bluequartz wrote:

My vote is for TBB to adopt the CMake build system then they don't have to worry about shipping 3 different visual studio solutions and Makefiles and have NO installation capability. It would be much nice to just use CMake to build TBB. With that you get the ability to support lots of different IDEs or plain makefiles for those who would like to contribute. You also get packaging support for many different types of distributions from NSIS to Zip to shell to tar.gz to .dmgs. This also gives TBB the ability to add in additional package files to the installation to make integrating with other build systems and other projects much simpler and straight forward.

From my point of view looking in from the outside, TBB may be "open-source" but the barrier to entry is so high for a developer coming from the outside that it just is not worth the cost of time to try to figure out how to add anything to TBB. This is another reason why I don't update my TBB installations. The time to do so should be minimal.

I will give kudos to the TBB team for releasing lots of variations of the libraries for the Visual Studio platforms. These releases have saved me from trying to build TBB myself.

Mike Jackson (dream3d.bluequartz.net)

absolutely not, I'm against cmake becase it's not a simple tool to implement or to deal with and it's not even officially available for all the major platform.

Even more it's an extra dependency that you don't need because it's not essential.

With cmake you are just adding an extra level that is not even granted to solve your problems, and you still need to add extra parameters 99.9% of the time.

Visual Studio is also the only environment is absolutely cumbersome, they change file format for the projects every time just to sell yet another version of the same bugged compiler and standard library.

[bluequartz]

Which "major" platforms is it missing for?

I see it as essential because the current build system is a failure in that respect and it needs to be replaced with something that works. Clearly by the shear lack of ability to add a "make install" or "make package" to the current build system something needs to be done.

And lastly, get off your "High hoarse" about development environments. You may dislike Microsoft and everything they stand for. That is your business and your opinion. The fact of the matter is that for TBB to get traction and KEEP that traction they need to support Visual Studio because like it or not Visual Studio is used by a LOT of developers. Some happily. Some not so happily. But it is used every day and is a major player on the Windows development scene. I have to use everything from makefiles and emacs, to QtCreator, to Xcode to Eclipse, to Visual Studio 2008, 2010, 2012 and now 2013. I have my favorites but I have to support them ALL with my projects. Cumbersome or not.

Cheers
Mike Jackson

[Vladimir_P_1234567890]

Jaak Ristioja (Cybernetica AS) wrote:

I can't access that because I'm still waiting for Intel Support to fix login at the URL you mentioned.

Sorry for inconvenience, the problem with authorization on open source site was fixed. 

Jaak Ristioja (Cybernetica AS) wrote:

PS: For extra synergy, have you considered publishing the TBB code repositories in public so people could submit code merge requests?

Yes, we are evaluating a feedback from our www.openmprtl.org and www.cilkplus.org projects to find out a repository solution that would better fit to our needs but there is no ETA yet. And you should know that there is no "perfect" source control system and we will always have users who will dislike any selected solution:)

--Vladimir

[bp]

bluequartz wrote:

Which "major" platforms is it missing for?

I see it as essential because the current build system is a failure in that respect and it needs to be replaced with something that works. Clearly by the shear lack of ability to add a "make install" or "make package" to the current build system something needs to be done.

And lastly, get off your "High hoarse" about development environments. You may dislike Microsoft and everything they stand for. That is your business and your opinion. The fact of the matter is that for TBB to get traction and KEEP that traction they need to support Visual Studio because like it or not Visual Studio is used by a LOT of developers. Some happily. Some not so happily. But it is used every day and is a major player on the Windows development scene. I have to use everything from makefiles and emacs, to QtCreator, to Xcode to Eclipse, to Visual Studio 2008, 2010, 2012 and now 2013. I have my favorites but I have to support them ALL with my projects. Cumbersome or not.

Cheers
Mike Jackson

There are a lot of technologies from Microsoft that I like, some of which I use everyday, but the C/C++ support under Visual Studio is ages behind any other major competitor like clang or gcc, even mingw is way better than VS.

When you go to public talks or you read official blogs, VS is the only environment with associated statements such as "we introduced this feature yesterday but we discovered that it was already bugged at the moment of the adoption", "we don't plan to introduce full support for C but we support the C++ standard", "the standard library is bugged but we will work this out on the next 1-2 year if you are lucky" .

Doesn't make any sense to code in C/C++ under VS, any big project, anyone, that is cross-platform and written in C/C++, when comes to supporting Windows it starts deteriorating, with strange inclusions and syntax gibrish and most of the time it doesn't even work properly on more than 2 versions of Windows.

If you look at what the ISO standard says and you look back at what Microsoft is shipping, it's a fact that this compiler is used because is "popular", not because it's good, you can't say that a compiler that still doesn't correctly support the C99 standard, with no future for C11, it's a compiler worth adopting ( and the new C++11 it's just a mess ), it's a statement that doesn't make any sense at all, "happy people vs unhappy people" ( free world vs closed source world, evil vs good ... etc etc ) it's a statement that you can adopt for any kind of comparison, even ice creams, so let's try to stay competent and objective, shall we ?

There are OSs that are re-writing or improving their own standard libraries from the ground up, we are debating a compiler that has not even a single feature worth mentioning that clearly shines above the other competitors. If you are forced to use VS because of the ABI or because of anything else, doesn't mean that it becomes a good compiler, you are simply doing your work and you don't have a choice.

going back to make; with make you write command line arguments and text files, with cmake you do basically the same: what is the difference at a practical level ? nothing. The real difference is that you are adding a dependency that probably even requires a specific version of cmake and that specific version it's not even probably granted to satisfy your requirement or become a good investment for the future.

Take a look at the scripts in the build directory and tell me how many of the supported platforms "benefits" from a version of cmake that is officially supported from Kitware at the present day.

[Anton_M_Intel]

We took a look at the possibility of CMake-based build system some time ago. Our impression was that CMake is only able to generate projects with absolute paths and other environment-specific settings for the given invocation on the given machine. But we need to ship *generic* makefiles and VS projects anyway as we ship them today. So, our conclusion was that CMake lacks flexibility that we need to produce generic output, and thus we cannot base our build system on top of it.

However, I see your point about standard interfaces to our build system (not sure however how to implement install target correctly given specific requirements of TBB usage model.. but it is a separate question) and I'd be happy to make TBB more convenient for CMake users. And here is the idea.

Do you know how VS projects are generated by our build system? Special script mimics a compiler and so receives a list of files and settings to build TBB, which in turn used to sync VS projects in accordance with our makefiles. I think the same way we could generate a CMake (or any other) project if necessary and it should not take too much effort or cause any significant objections.

As usual, a contribution (either wholly integrated or just a template/example of CMake project) and a list of customers who need this solution would be highly appreciated.

[bluequartz]

It is funny that those new to the way of CMake thinking all have the same issue. The VS projects have absolute paths and they see that as a problem because they want to ship the VS solution files. But that is the wrong way to think about the problem. You STOP shipping the makefiles and the Visual Studio projects and START shipping the CMake files*** This alleviates the TBB developers of having to maintain scripts and such to generate all the different VS solutions and makefiles. You have one set of CMake files that a TBB developer uses to generate the "project" files that they can use in their favorite environment. In this context I mean "project" files to be anything from VS solutions to Xcode project files to Makefiles to Eclipse, CodeBlocks, QtCreator and a more. CMake brings to the table the ability to use CPack to package your product using any number of platform specific technologies: From Linux packages to .zip, .tar.gz, .dmg (OS X), package maker (OS X), NSIS, and a few more. This allows your build farm to automatically generate any number of variations of the installers.

And as far as the dependencies on CMake go I do not see the problem for 99% of the developers out there. In order to develop one needs a certain set of tools. Some come standard on systems, some do not. Asking a developer to download something rather small (or just build it from source with ./configure; make; make install).

For example, if the TBB repositories switch to mercurial, I could argue that the switch isn't fair because I now have to download a mercurial client (My vote goes for Git with GitHub). The same goes for CMake. This is what TBB has settled on using and really, downloading CMake is a pretty low barrier to entry.

I realize that ripping out your current build system and replacing it with another is not something to be taken lightly, and I am not. It is just that I have seen how the switch can impact for the better a project allowing the project to concentrate on writing codes and not just trying to upkeep IDE specific project files.

Plus if you embrace the CTest portion of CMake with a public CDash server then you can leverage the communities willingness to setup their own build and testing machines that report the results back to your CDash server giving you instant feedback if new changes are working across the assortment of environments that developers are using.

*** The HDF5 project took a hybrid approach when we helped them switch to CMake. They "Officially" support CMake on Windows so they don't have to keep up all the various VS solutions. We make sure that the CMake build system works on OS X and Linux also through the public CDash test reporting site. This seems to have worked out very well for them as they no longer have to keep up to date with 4 flavors of VS (2008, 2010, 2012 and now 2013) but developers can now generate Xcode, Eclipse, CodeBlocks and QtCreator projects on the various platforms so they can work how they want to work.

Thanks for Listening

Mike Jackson

[Ryan_S_]

On behalf of the MacPorts package management system, I would like to reiterate the request in this thread: please offer a "make install" target.

[Vladimir_P_1234567890]

hello Ryan,

As we have written above we can consider adding this in case we get a contribution to better understand what is needed.

--Vladimir