Consider using CMake as the multi-platform build system #266
Comments
|
Hi Hans, What benefit do you see CMake bringing over the MPC tool used now? Thanks, From: Hans Johnson [mailto:notifications@github.com] Dear DOCGroup team, I am considering adding a parallel CMake based multi-platform build system to the existing ACE_TAO code base. Before I put forth such an effort, I want to make sure that you would consider incorporating it. Hans — |
|
Hi - On 30 Jun 2016, at 10:38, Steve Huston wrote:
The only thing that comes to mind: It unfortunately has become somewhat I personally think that if someone is going to spend time developing a
/-Will |
|
Given the thousands of projects and all features we have in MPC I think it is a huge amount of work to do that all again using some other tool. Maybe you can generate the CMake files using MPC, that would be probably much less work and would give you as user the benefit of using CMake to trigger your compiler. |
|
It wouldn't be a terrible idea to distribute a cmake module that user applications use, but I'm not sure it's productive to replace the main build system or to write a CMake backend for MPc. Sent from my iPhone
|
|
That idea (a cmake find module) I like a lot. From: William R. Otte [mailto:notifications@github.com] It wouldn't be a terrible idea to distribute a cmake module that user applications use, but I'm not sure it's productive to replace the main build system or to write a CMake backend for MPc. Sent from my iPhone
— |
|
The cmake file module sounds a good proposal |
|
I think you have the wrong impression of what cmake is. It is NOT a replacement for make or ninja or Visual studio. CMake is a build environment generator that does many of the features of MPC, but in many cases in a much more robust way. “CMake is an open-source, cross-platform family of tools designed to build, test and package software. CMake is used to control the software compilation process using simple platform and compiler independent configuration files, and generate native makefiles and workspaces that can be used in the compiler environment of your choice. The suite of CMake tools were created by Kitware in response to the need for a powerful, cross-platform build environment for open-source projects such as ITK and VTK.” The most important reason is: CMake is becoming the “lingua franca of the open source C++ community” and has been adopted by too many projects to list (Netflix, HDF5, OpenCV, LAPACK, LLVM, MikTex, KDE, QT, ITK, VTK, VXL to name just a few). The compiler introspection capabilities, support of user controlled options, parallel build capabilities, automatic dependency generation, support for various development environments, and support from the huge user community are just a few of it’s benefits. The cmake program has been bundled with nearly every linux distribution for a decade (and is very easy to install on windows, mac, linux, unix) CMake has modules for KDevelop, vim, emacs, CLion, Visual Studio to assist with writing the CMakeLists.txt files. There are built in testing capabilities that can facilitate regression testing. From a single source tree (with CMakeLists.txt declaration file), one can simultaneously generate 24 independent build environments using different environment generators https://cmake.org/cmake/help/v3.0/manual/cmake-generators.7.html These generators are rigorously tested each night in a rigorously tested on many (>100) environments every night (https://open.cdash.org/index.php?project=CMake) ) Adding a few CMakeLists.txt files to the source tree is all that would be the only disruption. It would not interfere with the current build system. I just want to make sure that CMake would be considered for inclusion before I put forth the effort of writing those files. Hans From: Steve Huston notifications@github.com That idea (a cmake find module) I like a lot. From: William R. Otte [mailto:notifications@github.com] It wouldn't be a terrible idea to distribute a cmake module that user applications use, but I'm not sure it's productive to replace the main build system or to write a CMake backend for MPc. Sent from my iPhone
— — |
|
I am not against adding cmake support but adding cmake files means double maintenance, when there are changes people need to maintain cmake and MPC files. We had that some time with autoconf which resulted in issues because not both where updated which lead to the removal of the autoconf files at some point. That is why I proposed to generate the cmake files, all information should be in the MPC files and making a basic generator should be too complex. |
|
I led the effort to use CMake for Apache Qpid, so I’m very aware of what CMake does. Back to my original question… what do you see as the benefits of adding CMake over what MPC does for ACE+TAO today? -Steve From: Hans Johnson [mailto:notifications@github.com] I think you have the wrong impression of what cmake is. It is NOT a replacement for make or ninja or Visual studio. CMake is a build environment generator that does many of the features of MPC, but in many cases in a much more robust way. “CMake is an open-source, cross-platform family of tools designed to build, test and package software. CMake is used to control the software compilation process using simple platform and compiler independent configuration files, and generate native makefiles and workspaces that can be used in the compiler environment of your choice. The suite of CMake tools were created by Kitware in response to the need for a powerful, cross-platform build environment for open-source projects such as ITK and VTK.” The most important reason is: CMake is becoming the “lingua franca of the open source C++ community” and has been adopted by too many projects to list (Netflix, HDF5, OpenCV, LAPACK, LLVM, MikTex, KDE, QT, ITK, VTK, VXL to name just a few). The compiler introspection capabilities, support of user controlled options, parallel build capabilities, automatic dependency generation, support for various development environments, and support from the huge user community are just a few of it’s benefits. The cmake program has been bundled with nearly every linux distribution for a decade (and is very easy to install on windows, mac, linux, unix) CMake has modules for KDevelop, vim, emacs, CLion, Visual Studio to assist with writing the CMakeLists.txt files. There are built in testing capabilities that can facilitate regression testing. From a single source tree (with CMakeLists.txt declaration file), one can simultaneously generate 24 independent build environments using different environment generators https://cmake.org/cmake/help/v3.0/manual/cmake-generators.7.html These generators are rigorously tested each night in a rigorously tested on many (>100) environments every night (https://open.cdash.org/index.php?project=CMake) ) Adding a few CMakeLists.txt files to the source tree is all that would be the only disruption. It would not interfere with the current build system. I just want to make sure that CMake would be considered for inclusion before I put forth the effort of writing those files. Hans From: Steve Huston <notifications@github.commailto:notifications@github.com> That idea (a cmake find module) I like a lot. From: William R. Otte [mailto:notifications@github.com] It wouldn't be a terrible idea to distribute a cmake module that user applications use, but I'm not sure it's productive to replace the main build system or to write a CMake backend for MPc. Sent from my iPhone
— — — |
|
I can not currently make a feature comparison between CMake or MPC because I do not know MPC. My guess is that there are many similarities. The primary benefit is community knowledge of how it works. The current build system for ACE has been a major stumbling block for myself and my collegues to get started. It is probably because we don’t understand how MPC works, but in navigating the help web pages, it took several hours to figure out. We know autoconf tools and cmake tools. Other packages that use either of those tools have required 5-10 minutes to figure out how to use. We have been fighting with ACE builds for more than a day on 1 platform. There are so many moving parts. I tried to run the build process from the “.travis.yml” build procedure on my SUSE linux machine, and it almost worked. The problem is that the linker command lines are not working on that platform. GNUmakefile: /nfs/s-iibi60/users-1/johnsonhj/src/ACE_TAO/ACE/ace/QtReactor/GNUmakefile.ACE_Qt4Reactor_moc MAKEFLAGS=w -j --jobserver-fds=4,5 ld -I/user/iibi/johnsonhj/src/ACE_TAO/ACE -DACE_NDEBUG -D__ACE_INLINE__ -L/user/iibi/johnsonhj/src/ACE_TAO/ACE/lib -L. -o UnloadLibACE .obj/Unload_libACE.o GNUmakefile: /nfs/s-iibi60/users-1/johnsonhj/src/ACE_TAO/ACE/tests/GNUmakefile.Library_Unload MAKEFLAGS=w -j --jobserver-fds=4,5 ld: unrecognized option '-DACE_NDEBUG' ld: use the --help option for usage information My initial guess is that the build files are passing all “Compiler flags” to the “Linker”. This is where I am currently stuck. I’ll need to learn MPC to be able to debug this and use ACE. I think I have gotten the response I need to move forward. It appears that there is not going to be support for incorporating CMake into the upstream version. Thank you for your consideration. Hans From: Steve Huston notifications@github.com I led the effort to use CMake for Apache Qpid, so I’m very aware of what CMake does. Back to my original question… what do you see as the benefits of adding CMake over what MPC does for ACE+TAO today? -Steve From: Hans Johnson [mailto:notifications@github.com] I think you have the wrong impression of what cmake is. It is NOT a replacement for make or ninja or Visual studio. CMake is a build environment generator that does many of the features of MPC, but in many cases in a much more robust way. “CMake is an open-source, cross-platform family of tools designed to build, test and package software. CMake is used to control the software compilation process using simple platform and compiler independent configuration files, and generate native makefiles and workspaces that can be used in the compiler environment of your choice. The suite of CMake tools were created by Kitware in response to the need for a powerful, cross-platform build environment for open-source projects such as ITK and VTK.” The most important reason is: CMake is becoming the “lingua franca of the open source C++ community” and has been adopted by too many projects to list (Netflix, HDF5, OpenCV, LAPACK, LLVM, MikTex, KDE, QT, ITK, VTK, VXL to name just a few). The compiler introspection capabilities, support of user controlled options, parallel build capabilities, automatic dependency generation, support for various development environments, and support from the huge user community are just a few of it’s benefits. The cmake program has been bundled with nearly every linux distribution for a decade (and is very easy to install on windows, mac, linux, unix) CMake has modules for KDevelop, vim, emacs, CLion, Visual Studio to assist with writing the CMakeLists.txt files. There are built in testing capabilities that can facilitate regression testing. From a single source tree (with CMakeLists.txt declaration file), one can simultaneously generate 24 independent build environments using different environment generators https://cmake.org/cmake/help/v3.0/manual/cmake-generators.7.html These generators are rigorously tested each night in a rigorously tested on many (>100) environments every night (https://open.cdash.org/index.php?project=CMake) ) Adding a few CMakeLists.txt files to the source tree is all that would be the only disruption. It would not interfere with the current build system. I just want to make sure that CMake would be considered for inclusion before I put forth the effort of writing those files. Hans From: Steve Huston <notifications@github.commailto:notifications@github.com> That idea (a cmake find module) I like a lot. From: William R. Otte [mailto:notifications@github.com] It wouldn't be a terrible idea to distribute a cmake module that user applications use, but I'm not sure it's productive to replace the main build system or to write a CMake backend for MPc. Sent from my iPhone
— — — — |
|
On 30 Jun 2016, at 13:26, Steve Huston wrote:
Particularly given that end users need not be exposed to the way ACE+TAO /-Will |
|
The full packages contain gnu makefiles and visual studio solutions, using those packages people don't need to use MPC at all. I build ACE+TAO daily on OpenSuSE, no problems. |
|
We also have RPMs for SuSE, see http://download.dre.vanderbilt.edu/ at the bottom of the page. For Linux we normally run in the ACE_wrappers/TAO directory the following commands (after we have set ACE_ROOT and TAO_ROOT as environment variables and add $ACE_ROOT/lib to the LD_LIBRARY_PATH) |
|
I have not been able to find working build instructions. The from the uncompressed download (ACE-6.3.4.tar.bz2) README file points to: http://www.dre.vanderbilt.edu/~schmidt/ACE-install.html which points to http://www.dre.vanderbilt.edu/~schmidt/DOC_ROOT/ACE/ACE-INSTALL.html which points to: http://www.dre.vanderbilt.edu/~schmidt/DOC_ROOT/ACE/ACE-INSTALL.html#unix Here is the 7 step process that almost seems to work: This fails to build. I'm still investigating. Could you please comment if that is approximately what the expected build proceedure is? Thank you. (Unfortunately I can not use the RPM's, I don't have root access to these machines). |
|
Hi Hans - On 30 Jun 2016, at 15:43, Hans Johnson wrote:
Those instructions should work.
Why?
Avoid setting INSTALL_PREFIX, at least for now. ‘make install’ has I’d also suggest export PATH=$ACE_ROOT/bin:$PATH I haven’t done daily development on ACE+TAO in a couple years, which https://github.com/DOCGroup/ACE_TAO/blob/master/.travis.yml If you remind me, I’ll have some time next week to take a quick look.
Are you only compiling for OS X? I may have a homebrew recipe lying thanks, |
|
I thought you where using Linux, looks you are using the configuration files for MacOSX, is that correct? I have made some small improvements to ACE-INSTALL.html, also updated the README to point to the local ACE-INSTALL.html file that we ship in the package. We currently don't have daily builds for MacOSX due to a lack of sponsoring. |
|
Btw, homebrew does have ACE, see https://github.com/Homebrew/homebrew-core/blob/master/Formula/ace.rb |
|
William thank you for the very helpful response. It is good to know that I am at least on the right track. I am trying to build one version for Mac, and one version for SUSE Linux. --Linux is most important. --I have installed the homebrew version on mac, but my bull-headed stubbornness requires that I build any tool I will depend on from scratch at least once J. Here is my latest SUSE build failure: LSB Version: core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-x86_64:core-3.2-x86_64:core-4.0-x86_64:desktop-4.0-amd64:desktop-4.0-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch Distributor ID: openSUSE project Description: openSUSE 13.2 (Harlequin) (x86_64) Release: 13.2 Codename: Harlequin g++ --version g++ (SUSE Linux) 4.8.3 20140627 [gcc-4_8-branch revision 212064] === ERROR #1 ==== make[1]: Entering directory '/tmp/ACE_wrappers/ace' GNUmakefile: /tmp/ACE_wrappers/ace/GNUmakefile.ACE MAKEFLAGS=w g++ -fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -fvisibility=hidden -fvisibility-inlines-hidden -Wnon-virtual-dtor -O3 -ggdb -m64 -pthread -fno-strict-aliasing -Wall -W -Wpointer-arith -pipe -D_GNU_SOURCE -I/usr/share/ace -DACE_NO_INLINE -I.. -DACE_BUILD_DLL -c -fPIC -o .shobj/UUID.o UUID.cpp UUID.cpp: In member function ‘void ACE_Utils::UUID_Generator::generate_UUID(ACE_Utils::UUID&, ACE_UINT16, u_char)’: UUID.cpp:409:41: error: no matching function for call to ‘ACE_Thread_ID::to_string(char [8192], int)’ thread_id.to_string (buf, BUFSIZ); ^ UUID.cpp:409:41: note: candidate is: In file included from /usr/share/ace/ace/Thread_Mutex.h:31:0, from /usr/share/ace/ace/TSS_T.h:38, from /usr/share/ace/ace/Singleton.h:24, from /usr/share/ace/ace/UUID.h:26, from UUID.cpp:1: /usr/share/ace/ace/OS_NS_Thread.h:724:8: note: void ACE_Thread_ID::to_string(char*) const void to_string (char *thr_string) const; ^ /usr/share/ace/ace/OS_NS_Thread.h:724:8: note: candidate expects 1 argument, 2 provided /usr/share/ace/include/makeinclude/rules.local.GNU:188: recipe for target '.shobj/UUID.o' failed make[1]: *** [.shobj/UUID.o] Error 1 make[1]: Leaving directory '/tmp/ACE_wrappers/ace' GNUmakefile:771: recipe for target 'ACE' failed make: *** [ACE] Error 2 === ERROR #2 ===== make[1]: Entering directory '/nfs/s-iibi60/users-1/johnsonhj/src/ACE_wrappers/ace' GNUmakefile: /nfs/s-iibi60/users-1/johnsonhj/src/ACE_wrappers/ace/GNUmakefile.ACE MAKEFLAGS=w g++ -pthread -Wl,-O3 -shared -Wl,-h -Wl,libACE.so.6.3.0 -o libACE.so.6.3.0 .shobj/Local_Name_Space.o .shobj/Name_Proxy.o .shobj/Name_Request_Reply.o .shobj/Name_Space.o .shobj/Naming_Context.o .shobj/Registry_Name_Space.o < Removed many files here> .shobj/WIN32_Asynch_IO.o .shobj/WIN32_Proactor.o .shobj/XTI_ATM_Mcast.o -m64 -Wl,-E -L../lib -L. -L../lib -ldl –lrt /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: .shobj/Local_Name_Space.o: relocation R_X86_64_32 against `_ZSt7nothrow' can not be used when making a shared object; recompile with -fPIC .shobj/Local_Name_Space.o: error adding symbols: Bad value collect2: error: ld returned 1 exit status /usr/share/ace/include/makeinclude/rules.lib.GNU:242: recipe for target 'libACE.so.6.3.0' failed make[1]: *** [libACE.so.6.3.0] Error 1 make[1]: Leaving directory '/nfs/s-iibi60/users-1/johnsonhj/src/ACE_wrappers/ace' GNUmakefile:771: recipe for target 'ACE' failed make: *** [ACE] Error 2 From: "William R. Otte" notifications@github.com Hi Hans - On 30 Jun 2016, at 15:43, Hans Johnson wrote:
Those instructions should work.
Why?
Avoid setting INSTALL_PREFIX, at least for now. ‘make install’ has I’d also suggest export PATH=$ACE_ROOT/bin:$PATH I haven’t done daily development on ACE+TAO in a couple years, which https://github.com/DOCGroup/ACE_TAO/blob/master/.travis.yml If you remind me, I’ll have some time next week to take a quick look.
Are you only compiling for OS X? I may have a homebrew recipe lying thanks, — |
|
Are you 100% sure that ACE_ROOT is set correctly, it looks it should point to /tmp/ACE_wrappers/ but I also see /usr/share/ace as path, are you maybe mixing two ACE versions in two different locations on your system? |
|
ARRG... My ssh session died, and I re-logged back in. I forgot that environmental variables are required for the build. I'll start over again. |
|
Are parallel builds supported (make -j 8) ? |
|
Yes, should work |
|
Hi Hans - On 1 Jul 2016, at 7:40, Hans Johnson wrote:
I hope so. The amount of time I spent getting that to work right was I had a brain fart and grabbed the latest release instead of the latest 503 wget It had a bunch of easily fixable warnings, but no errors. I didn’t If you’re going to be depending on ACE working on OS X, I highly hth, |
|
On the topic of CMake, my understanding is that Boost makes available a "FindBoost" cmake thing (either through boost.org itself or directly in CMake) that allows downstream users to set up their projects (that use Boost) with CMake. This strikes me as the right direction for ACE (+TAO et al) to take. Please post any questions you have while developing such a thing and we'll be sure to answer them. Perhaps the existing support for pkg-config would be a good starting point or reference. |
|
Is there a way to specify an external build directory (e.g. building all .o in a separate build folder like |
|
@alexchandel please open a new issue |
But on windows (with generated solution) there is NO install target and NO possibility to run tests? And a lot of problems are not found, because of the completely different directory structure und stupid visual studio 2017/19! |
There exist a usable starting module: see https://github.com/ClausKlein/cmake-modules/blob/develop/FindTAO.cmake Not as simple and clean as it should, but it works! |
https://github.com/objectcomputing/OpenDDS contains CMake support for building applications that use OpenDDS (which means they also use ACE_TAO). |
|
See DOCGroup/MPC#164 for a MPC related effort |
|
Fully supporting CMake would be great. I'm trying to integrate with other libraries and ACE+TAO's MPC is the odd library out. Boost has In the meantime, what is currently the best way to import ACE+TAO in a CMake project? |
|
Using ACE+TAO in a downstream CMake project (like FindBoost does for Boost) has been possible for quite a while using the code that we provided as part of OpenDDS (see comment above from 2021-07-07). One could extract just the ACE+TAO parts of those CMake modules. |
Dear DOCGroup team,
I am considering adding a parallel CMake based multi-platform build system to the existing ACE_TAO code base. Before I put forth such an effort, I want to make sure that you would consider incorporating it.
Hans
The text was updated successfully, but these errors were encountered: