ACE_TAO
ACE_TAO copied to clipboard
DOCGroup
Consider using CMake as the multi-platform build system
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 Hans,
What benefit do you see CMake bringing over the MPC tool used now?
Thanks, -Steve
From: Hans Johnson [mailto:[email protected]] Sent: Thursday, June 30, 2016 11:34 AM To: DOCGroup/ACE_TAO [email protected] Subject: [DOCGroup/ACE_TAO] Consider using CMake as the multi-platform build system (#266)
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
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/DOCGroup/ACE_TAO/issues/266, or mute the threadhttps://github.com/notifications/unsubscribe/AAAwvrG1vkmn9qDISsRZD5Cf-a1xgjoSks5qQ-HUgaJpZM4JCSgN.
Hi -
On 30 Jun 2016, at 10:38, Steve Huston wrote:
Hi Hans,
What benefit do you see CMake bringing over the MPC tool used now?
The only thing that comes to mind: It unfortunately has become somewhat of the lingua franca of the open source C++ community, so it would allow someone to build with a tool they probably already have on their machine.
I personally think that if someone is going to spend time developing a new build system for A+T(+C+D), it would be better done with waf (https://github.com/waf-project/waf) which:
- Is entirely contained within the project. Users only need to have some sane version of python installed, which they probably will these days (and not have perl installed)
- Since it is entirely contained and has no external dependencies, we always know which version is used to build.
- It is easier to extend to support some of our wonky build processes, and doesn’t require anyone to look at that awful abortion of a language that CMake uses.
- It’s shiny.
/-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
On Jun 30, 2016, at 12:32 PM, Johnny Willemsen [email protected] wrote:
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.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
That idea (a cmake find module) I like a lot.
From: William R. Otte [mailto:[email protected]] Sent: Thursday, June 30, 2016 1:40 PM To: DOCGroup/ACE_TAO [email protected] Cc: Steve Huston [email protected]; Comment [email protected] Subject: Re: [DOCGroup/ACE_TAO] Consider using CMake as the multi-platform build system (#266)
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 Jun 30, 2016, at 12:32 PM, Johnny Willemsen <[email protected]mailto:[email protected]> wrote:
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.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/DOCGroup/ACE_TAO/issues/266#issuecomment-229733597, or mute the threadhttps://github.com/notifications/unsubscribe/AAAwvlvPGxGS37vaXn6XkQLbI2vYEpQFks5qQ_-JgaJpZM4JCSgN.
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 Borland Makefiles MSYS Makefiles MinGW Makefiles NMake Makefiles NMake Makefiles JOM Ninja Unix Makefiles Watcom WMake Visual Studio 6 Visual Studio 7 Visual Studio 7 .NET 2003 Visual Studio 8 2005 Visual Studio 9 2008 Visual Studio 10 2010 Visual Studio 11 2012 Visual Studio 12 2013 Xcode CodeBlocks CodeLite Eclipse CDT4 KDevelop3 Kate Sublime Text 2
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 [email protected] Reply-To: DOCGroup/ACE_TAO [email protected] Date: Thursday, June 30, 2016 at 12:46 PM To: DOCGroup/ACE_TAO [email protected] Cc: Hans Johnson [email protected], Author [email protected] Subject: Re: [DOCGroup/ACE_TAO] Consider using CMake as the multi-platform build system (#266)
That idea (a cmake find module) I like a lot.
From: William R. Otte [mailto:[email protected]] Sent: Thursday, June 30, 2016 1:40 PM To: DOCGroup/ACE_TAO [email protected] Cc: Steve Huston [email protected]; Comment [email protected] Subject: Re: [DOCGroup/ACE_TAO] Consider using CMake as the multi-platform build system (#266)
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 Jun 30, 2016, at 12:32 PM, Johnny Willemsen <[email protected]mailto:[email protected]> wrote:
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.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/DOCGroup/ACE_TAO/issues/266#issuecomment-229733597, or mute the threadhttps://github.com/notifications/unsubscribe/AAAwvlvPGxGS37vaXn6XkQLbI2vYEpQFks5qQ_-JgaJpZM4JCSgN.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
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:[email protected]] Sent: Thursday, June 30, 2016 2:19 PM To: DOCGroup/ACE_TAO [email protected] Cc: Steve Huston [email protected]; Comment [email protected] Subject: Re: [DOCGroup/ACE_TAO] Consider using CMake as the multi-platform build system (#266)
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 Borland Makefiles MSYS Makefiles MinGW Makefiles NMake Makefiles NMake Makefiles JOM Ninja Unix Makefiles Watcom WMake Visual Studio 6 Visual Studio 7 Visual Studio 7 .NET 2003 Visual Studio 8 2005 Visual Studio 9 2008 Visual Studio 10 2010 Visual Studio 11 2012 Visual Studio 12 2013 Xcode CodeBlocks CodeLite Eclipse CDT4 KDevelop3 Kate Sublime Text 2
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 <[email protected]mailto:[email protected]> Reply-To: DOCGroup/ACE_TAO <[email protected]mailto:[email protected]> Date: Thursday, June 30, 2016 at 12:46 PM To: DOCGroup/ACE_TAO <[email protected]mailto:[email protected]> Cc: Hans Johnson <[email protected]mailto:[email protected]>, Author <[email protected]mailto:[email protected]> Subject: Re: [DOCGroup/ACE_TAO] Consider using CMake as the multi-platform build system (#266)
That idea (a cmake find module) I like a lot.
From: William R. Otte [mailto:[email protected]] Sent: Thursday, June 30, 2016 1:40 PM To: DOCGroup/ACE_TAO <[email protected]mailto:[email protected]> Cc: Steve Huston <[email protected]mailto:[email protected]>; Comment <[email protected]mailto:[email protected]> Subject: Re: [DOCGroup/ACE_TAO] Consider using CMake as the multi-platform build system (#266)
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 Jun 30, 2016, at 12:32 PM, Johnny Willemsen <[email protected]<mailto:[email protected]mailto:[email protected]%3cmailto:[email protected]>> wrote:
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.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/DOCGroup/ACE_TAO/issues/266#issuecomment-229733597, or mute the threadhttps://github.com/notifications/unsubscribe/AAAwvlvPGxGS37vaXn6XkQLbI2vYEpQFks5qQ_-JgaJpZM4JCSgN.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/DOCGroup/ACE_TAO/issues/266#issuecomment-229744504, or mute the threadhttps://github.com/notifications/unsubscribe/AAAwvosWrlVhEeF1lr5KaQyIYFBUrdS8ks5qRAh7gaJpZM4JCSgN.
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 [email protected] Reply-To: DOCGroup/ACE_TAO [email protected] Date: Thursday, June 30, 2016 at 1:26 PM To: DOCGroup/ACE_TAO [email protected] Cc: Hans Johnson [email protected], Author [email protected] Subject: Re: [DOCGroup/ACE_TAO] Consider using CMake as the multi-platform build system (#266)
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:[email protected]] Sent: Thursday, June 30, 2016 2:19 PM To: DOCGroup/ACE_TAO [email protected] Cc: Steve Huston [email protected]; Comment [email protected] Subject: Re: [DOCGroup/ACE_TAO] Consider using CMake as the multi-platform build system (#266)
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 Borland Makefiles MSYS Makefiles MinGW Makefiles NMake Makefiles NMake Makefiles JOM Ninja Unix Makefiles Watcom WMake Visual Studio 6 Visual Studio 7 Visual Studio 7 .NET 2003 Visual Studio 8 2005 Visual Studio 9 2008 Visual Studio 10 2010 Visual Studio 11 2012 Visual Studio 12 2013 Xcode CodeBlocks CodeLite Eclipse CDT4 KDevelop3 Kate Sublime Text 2
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 <[email protected]mailto:[email protected]> Reply-To: DOCGroup/ACE_TAO <[email protected]mailto:[email protected]> Date: Thursday, June 30, 2016 at 12:46 PM To: DOCGroup/ACE_TAO <[email protected]mailto:[email protected]> Cc: Hans Johnson <[email protected]mailto:[email protected]>, Author <[email protected]mailto:[email protected]> Subject: Re: [DOCGroup/ACE_TAO] Consider using CMake as the multi-platform build system (#266)
That idea (a cmake find module) I like a lot.
From: William R. Otte [mailto:[email protected]] Sent: Thursday, June 30, 2016 1:40 PM To: DOCGroup/ACE_TAO <[email protected]mailto:[email protected]> Cc: Steve Huston <[email protected]mailto:[email protected]>; Comment <[email protected]mailto:[email protected]> Subject: Re: [DOCGroup/ACE_TAO] Consider using CMake as the multi-platform build system (#266)
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 Jun 30, 2016, at 12:32 PM, Johnny Willemsen <[email protected]<mailto:[email protected]mailto:[email protected]%3cmailto:[email protected]>> wrote:
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.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/DOCGroup/ACE_TAO/issues/266#issuecomment-229733597, or mute the threadhttps://github.com/notifications/unsubscribe/AAAwvlvPGxGS37vaXn6XkQLbI2vYEpQFks5qQ_-JgaJpZM4JCSgN.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/DOCGroup/ACE_TAO/issues/266#issuecomment-229744504, or mute the threadhttps://github.com/notifications/unsubscribe/AAAwvosWrlVhEeF1lr5KaQyIYFBUrdS8ks5qRAh7gaJpZM4JCSgN.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
On 30 Jun 2016, at 13:26, Steve Huston wrote:
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?
Particularly given that end users need not be exposed to the way ACE+TAO is built internally.
/-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) perl $ACE_ROOT/bin/mwc.pl -type gnuace make
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:
cd ACE_wrappers
export ACE_ROOT=$(pwd)
echo '#include "ace/config-macosx-elcapitan.h"' > $ACE_ROOT/ace/config.h
echo 'include $(ACE_ROOT)/include/makeinclude/platform_macosx_elcapitan.GNU' > $ACE_ROOT/include/makeinclude/platform_macros.GNU
echo "INSTALL_PREFIX = /usr/local
echo "INSTALL_PREFIX = /tmp/ACE" >> $ACE_ROOT/include/makeinclude/platform_macros.GNU
export LD_LIBRARY_PATH=$ACE_ROOT/lib:$LD_LIBRARY_PATH
export DYLD_LIBRARY_PATH=$ACE_ROOT/lib:$DYLD_LIBRARY_PATH
make -j4
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:
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
Those instructions should work.
Here is the 7 step process that almost seems to work: cd ACE_wrappers export ACE_ROOT=$(pwd) echo '#include "ace/config-macosx-elcapitan.h"' > $ACE_ROOT/ace/config.h echo 'include $(ACE_ROOT)/include/makeinclude/platform_macosx_elcapitan.GNU' > $ACE_ROOT/include/makeinclude/platform_macros.GNU echo "INSTALL_PREFIX = /usr/local echo "INSTALL_PREFIX = /tmp/ACE" >> $ACE_ROOT/include/makeinclude/platform_macros.GNU export LD_LIBRARY_PATH=$ACE_ROOT/lib:$LD_LIBRARY_PATH export DYLD_LIBRARY_PATH=$ACE_ROOT/lib:$DYLD_LIBRARY_PATH make -j4
This fails to build.
Why?
I'm still investigating. Could you please comment if that is approximately what the expected build proceedure is?
Avoid setting INSTALL_PREFIX, at least for now. ‘make install’ has historically been a little wonky, and I’m not sure there’s a test build on OS X.
I’d also suggest
export PATH=$ACE_ROOT/bin:$PATH
I haven’t done daily development on ACE+TAO in a couple years, which means I haven’t built it on the last couple OS X releases (at one point I maintained the port). I couldn’t find an OS X build on the scoreboard (Johnny, Steve, do we have one?) to point you to, but this may be helpful:
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.
Thank you.
(Unfortunately I can not use the RPM's, I don't have root access to these machines).
Are you only compiling for OS X? I may have a homebrew recipe lying around, but that might have been a laptop or two ago. I can take a look.
thanks, /-Will
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" [email protected] Reply-To: DOCGroup/ACE_TAO [email protected] Date: Thursday, June 30, 2016 at 4:32 PM To: DOCGroup/ACE_TAO [email protected] Cc: Hans Johnson [email protected], Author [email protected] Subject: Re: [DOCGroup/ACE_TAO] Consider using CMake as the multi-platform build system (#266)
Hi Hans -
On 30 Jun 2016, at 15:43, Hans Johnson wrote:
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
Those instructions should work.
Here is the 7 step process that almost seems to work: cd ACE_wrappers export ACE_ROOT=$(pwd) echo '#include "ace/config-macosx-elcapitan.h"' > $ACE_ROOT/ace/config.h echo 'include $(ACE_ROOT)/include/makeinclude/platform_macosx_elcapitan.GNU' > $ACE_ROOT/include/makeinclude/platform_macros.GNU echo "INSTALL_PREFIX = /usr/local echo "INSTALL_PREFIX = /tmp/ACE" >> $ACE_ROOT/include/makeinclude/platform_macros.GNU export LD_LIBRARY_PATH=$ACE_ROOT/lib:$LD_LIBRARY_PATH export DYLD_LIBRARY_PATH=$ACE_ROOT/lib:$DYLD_LIBRARY_PATH make -j4
This fails to build.
Why?
I'm still investigating. Could you please comment if that is approximately what the expected build proceedure is?
Avoid setting INSTALL_PREFIX, at least for now. ‘make install’ has historically been a little wonky, and I’m not sure there’s a test build on OS X.
I’d also suggest
export PATH=$ACE_ROOT/bin:$PATH
I haven’t done daily development on ACE+TAO in a couple years, which means I haven’t built it on the last couple OS X releases (at one point I maintained the port). I couldn’t find an OS X build on the scoreboard (Johnny, Steve, do we have one?) to point you to, but this may be helpful:
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.
Thank you.
(Unfortunately I can not use the RPM's, I don't have root access to these machines).
Are you only compiling for OS X? I may have a homebrew recipe lying around, but that might have been a laptop or two ago. I can take a look.
thanks, /-Will
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
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.
Hi Hans -
On 1 Jul 2016, at 7:40, Hans Johnson wrote:
Are parallel builds supported (make -j 8) ?
I hope so. The amount of time I spent getting that to work right was horrendous.
I had a brain fart and grabbed the latest release instead of the latest micro, but the following compiled for me out of the box (I’m on ElCap):
503 wget http://download.dre.vanderbilt.edu/previous_versions/ACE-src-6.3.0.tar.bz2 504 tar xvf ACE-src-6.3.0.tar.bz2 505 cd ACE_wrappers/ 506 export ACE_ROOT=$PWD 507 export DYLD_LIBRARY_PATH=$ACE_ROOT/lib:$DYLD_LIBRARY_PATH 508 cp ace/config-macosx-yosemite.h ace/config.h 509 cp include/makeinclude/platform_macosx_yosemite.GNU include/makeinclude/platform_macros.GNU 510 $ACE_ROOT/bin/mwc.pl -type gnuace ACE.mwc 511 make -j8
It had a bunch of easily fixable warnings, but no errors. I didn’t run any tests, though, so I’ve got no idea if anything works.
If you’re going to be depending on ACE working on OS X, I highly recommend that you contribute a build to our scoreboard (not difficult), or engage the services of one of these fine folks on this thread to do so on your behalf.
hth, /-Will
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 /build/x86_64-apple-darwin/ACE_wrappers/ace/ rather than /src/ACE_wrappers/ace/.obj/) with the default generated makefiles? Or do the makefiles have to be regenerated with MPC? Or is such a thing only possible with CMake?
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.
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!
The cmake file module sounds a good proposal
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!
The cmake file module sounds a good proposal
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).