Consider using CMake as the multi-platform build system about ace_tao

[hjmjohnson]

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//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.

[shuston]

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//issues/266, or mute the threadhttps://github.com/notifications/unsubscribe/AAAwvrG1vkmn9qDISsRZD5Cf-a1xgjoSks5qQ-HUgaJpZM4JCSgN.

[wrotte]

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:

1. 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)
2. Since it is entirely contained and has no external dependencies, we
   always know which version is used to build.
3. 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.
4. It’s shiny.

/-Will

[jwillemsen]

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.

[wrotte]

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.

[shuston]

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//issues/266#issuecomment-229733597, or mute the threadhttps://github.com/notifications/unsubscribe/AAAwvlvPGxGS37vaXn6XkQLbI2vYEpQFks5qQ_-JgaJpZM4JCSgN.

[jwillemsen]

The cmake file module sounds a good proposal

[jwillemsen]

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.

[shuston]

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//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//issues/266#issuecomment-229744504, or mute the threadhttps://github.com/notifications/unsubscribe/AAAwvosWrlVhEeF1lr5KaQyIYFBUrdS8ks5qRAh7gaJpZM4JCSgN.

[hjmjohnson]

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//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//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.

[wrotte]

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

[jwillemsen]

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.

[jwillemsen]

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

[hjmjohnson]

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).

[wrotte]

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

[jwillemsen]

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.

[jwillemsen]

Btw, homebrew does have ACE, see https://github.com/Homebrew/homebrew-core/blob/master/Formula/ace.rb

[hjmjohnson]

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.

[jwillemsen]

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?

[hjmjohnson]

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.

[hjmjohnson]

Are parallel builds supported (make -j 8) ?

[jwillemsen]

Yes, should work

[wrotte]

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

[mitza-oci]

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.

[alexchandel]

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?

[mitza-oci]

@alexchandel please open a new issue

[ClausKlein]

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!

[ClausKlein]

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!

[mitza-oci]

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).

[jwillemsen]

See DOCGroup/MPC#164 for a MPC related effort

[alexchandel]

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 FindBoost.

In the meantime, what is currently the best way to import ACE+TAO in a CMake project?

[mitza-oci]

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.