Feature #10549

non-qualified products

Added by Ron Rechenmacher over 5 years ago. Updated over 5 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
(Total: 0.00 h)
Spent time:
(Total: 2.50 h)


We would like to build a flavored, non-qualified product in MRB.
I think that means cetbuildtools needs to support it.
We've emailed a 1 line patch to Lynn which may solve the issue.


Feature #10597: allow cetbuildtools to produce a product without a debug or prof qualifierAssignedLynn Garren

Feature #10598: use the native compiler with cetbuildtoolsAccepted

Feature #10599: rename the simple optionClosedLynn Garren


#1 Updated by Lynn Garren over 5 years ago

A bit more information from Ron:

More info about our use case is that we want mrb to be able to build TRACE
because another product we have (pcie_linux_kernel_module) depends on the TRACE kernel
module part of TRACE and we want to make sure we have a matching version.

Currently, the module part (which, of course, does not
interact with user space directly), needs to use the system compiler.
The lib and utility parts of the product use thread local storage and
atomic which is a relatively new features of C/C++ and should
not use the native compiler (on SLF6).
On SLF7, when it becomes available (very soon?), everything can use the native compiler.

#2 Updated by Lynn Garren over 5 years ago

It should be noted that the setup_for_devolopment.noarch template is specifically designed for NULL flavored products and the rest of the infrastructure in mrb and cetbuildtools associated with "simple" is designed to support a NULL flavored product.

There would appear to be several different concepts here.
  1. NULL flavored (nothing is compiled)
  2. there are no qualifiers
  3. use the native compiler

It is worth noting that the art team specifically requires a qualifier on all products which are built with a non-native compiler. cetbuildtools conforms to this requirement.

#3 Updated by Lynn Garren over 5 years ago

Hum, there is a fourth idea: building with a non-native compiler, but without specifying either debug or prof.

#4 Updated by Eric Flumerfelt over 5 years ago

The fourth option definitely sounds good for the library part of TRACE. We can play tricks in CMakeLists.txt to use the native compiler for the kernel module which requires it.

For right now, we can make a "e7:debug" build which would be used in all e7-based configurations, but it would be best to have a simple "e7" qualifier from our cetbuildtools-based build.

We'll deal with SLF7 when we get there.

#5 Updated by Lynn Garren over 5 years ago

I am concerned by the idea that you are using two different compilers within the same build. None of the infrastructure is designed to support that.

#6 Updated by Lynn Garren over 5 years ago

  • Status changed from New to Accepted

Also available in: Atom PDF