You can also do compiler flags on a per target basis using ` set_target_properties`: http://www.cmake.org/pipermail/cmake/2006-July/009992.html I would be concerned about colliding -O flags though. I don't know what the resolution on that is, or if it causes an error, if there is already a -O2 (for instance) given by the default ubuntu build flags. I'm not sure this flag is passed explicitly on the farm or not, but if it is, I don't know what will happen. Just something to look out for and test out I guess. On Mon, Jul 22, 2013 at 2:10 PM, Austin Hendrix wrote: > Most of the documentation I was reading regarding CMAKE_BUILD_TYPE > says that it should not be set by packages, and should be set by users > at configure or build time, so I was hesitant to use it for exactly > the reasons you describe. > > Since setting CMAKE_BUILD_TYPE seems like a bad idea, and the packages > I'm building should have optimizations turned on regardless of whether > they're built by a user from source or on the farm, and I don't care > about the other flags that are set by the Release build type, I did a > little more digging and found that I can add the optimization flag to > my build with: > > add_definitions(-O3) > > Which is set for my project and all subdirectories, but shouldn't > affect other cmake packages in the same workspace. > > > -Austin > > On Thu, Jul 18, 2013 at 11:17 AM, Tully Foote > wrote: > > I believe the buildfarm already runs Release. > > > > In general you don't want to set the build type from CMake that should > be a > > setting of the environment so that the person building the packages can > > choose what build type they want. It is very ugly to be required to > patch > > the source of a repo to change the build type. As we move toward > supporting > > cross compilation and leveraging the out of source builds, we need to get > > better about not putting build parameters into the source. > > > > The correct place to force this setting for the debians for example is in > > the debian/rules file. > > > > Tully > > > > > > On Thu, Jul 18, 2013 at 9:24 AM, William Woodall < > william@osrfoundation.org> > > wrote: > >> > >> If you set the CMAKE_BUILD_TYPE, you should do it in a already defined > >> guard: > >> > >> if(NOT DEFINED CMAKE_BUILD_TYPE) > >> set(CMAKE_BUILD_TYPE Release) > >> endif() > >> > >> That way it can still be explicitly overridden if desired. > >> > >> > >> On Thu, Jul 18, 2013 at 12:31 AM, Ruben Smits > >> wrote: > >>> > >>> Hi Austin, > >>> > >>> > >>> On Thu, Jul 18, 2013 at 4:25 AM, Austin Hendrix > >>> wrote: > >>>> > >>>> I have a few packages containing realtime controllers that were > >>>> previously built with: > >>>> set(ROS_BUILD_TYPE Release), which among other things enabled > >>>> optimizations as part of the build process. > >>>> > >>>> Since the catkin doesn't supply a replacement for ROS_BUILD_TYPE, I've > >>>> omitted it when catkinizing packages, but I'm discovering now that > >>>> packages compiled on the build farm are not sufficiently optimized for > >>>> my use case. > >>>> > >>>> Is there a way to enable optimizations or the Release build type, > >>>> either on the farm as a whole, in bloom, or in my packages? > >>>> > >>> > >>> For plain cmake packages or catkin you can use the CMAKE_BUILD_TYPE > >>> variable which takes the exact same values as rosbuilds ROS_BUILD_TYPE > >>> variable: > >>> > >>> set(CMAKE_BUILD_TYPE Release) > >>> > >>> see > http://www.cmake.org/Wiki/CMake_Useful_Variables#Compilers_and_Tools > >>> for more info > >>> > >>> Ruben > >>> > >>>> > >>>> -Austin > >>>> _______________________________________________ > >>>> Ros-release mailing list > >>>> Ros-release@code.ros.org > >>>> https://code.ros.org/mailman/listinfo/ros-release > >>> > >>> > >>> > >>> > >>> -- > >>> Ruben Smits, Phd > >>> Chief Technology Officer > >>> Intermodalics BVBA > >>> +32479511786 > >>> www.intermodalics.eu > >>> > >>> _______________________________________________ > >>> Ros-release mailing list > >>> Ros-release@code.ros.org > >>> https://code.ros.org/mailman/listinfo/ros-release > >>> > >> > >> > >> > >> -- > >> William Woodall > >> ROS Development Team > >> william@osrfoundation.org > >> http://williamjwoodall.com/ > >> > >> _______________________________________________ > >> Ros-release mailing list > >> Ros-release@code.ros.org > >> https://code.ros.org/mailman/listinfo/ros-release > >> > > > > > > _______________________________________________ > > Ros-release mailing list > > Ros-release@code.ros.org > > https://code.ros.org/mailman/listinfo/ros-release > > > -- William Woodall ROS Development Team william@osrfoundation.org http://williamjwoodall.com/