CMake support to build ACE+TAO including IDL targets #177

alexchandel · 2023-02-12T22:55:44Z

Combined with CMake scripts in this example, this PR enables building ACE+TAO with IDL generation (following #164). The example links two dozen different ACE+TAO libraries including some orbsvcs with no manual hard-coding.

I made minimal modifications, doing most in IDL_FILES_TARGET_SOURCES().

Key changes:

The minimum CMake had to be raised to 3.20, as before that, target_sources() silently failed when applied to targets from add_custom_command(). This causes sources generated from IDL into different directories to fail to be detected by CMake for dependency resolution purposes.
- This must be done for all CMakeLists, as if any parent file has version < 3.20, this bug occurs.
To handle IDL files, MPC custom_types (e.g. AnyTypeCode_Idl) are emitted as object library targets. They have to be something, as MPC sets several properties of the named target, including set_target_properties(), target_compile_definitions(), and target_link_directories(), which error otherwise. Also, the emitted IDL_FILES_TARGET_SOURCES() macro currently adds all generated sources to the target, to ensure CMake interprets them as being in the source directory for dependency purposes (won't happen otherwise, even though I tell CMake absolute paths). Note that these IDL object library targets are purely bookkeeping, and are not actually built.
- The scope passed to the macro is changed to PRIVATE, or else the following error occurs:

[100%] Building CXX object CMakeFiles/TrivialTest.dir/ACE_wrappers/TAO/orbsvcs/orbsvcs/RtecBaseC.cpp.o
In file included from /Users/dev/Downloads/Test/ACE_wrappers/TAO/orbsvcs/orbsvcs/RtecBaseC.cpp:29:
/Users/dev/Downloads/Test/ACE_wrappers/TAO/orbsvcs/orbsvcs/RtecBaseC.h:41:15: fatal error: 'orbsvcs/svc_utils_export.h' file not found
#include /**/ "orbsvcs/svc_utils_export.h"
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
make[2]: *** [CMakeFiles/TrivialTest.dir/ACE_wrappers/TAO/orbsvcs/orbsvcs/RtecBaseC.cpp.o] Error 1
make[1]: *** [CMakeFiles/TrivialTest.dir/all] Error 2
make: *** [all] Error 2

Considerations that went into this:

The object library target works, but…
- An interface library would also make more sense, for IDL files at least. However those can only have INTERFACE properties, while we set PUBLIC and PRIVATE properties.
- The most generic choice would be add_custom_target(), but that would require disabling the target_compile_definitions() and target_link_directories() for custom_only targets (which is doable) and also making the macro calls PRIVATE. It has other issues too.
- The most "CMake" thing would be to emit different targets for stub, skel, and anyop files, and have consumers link those (which would bring in the appropriate objects with the right scope). But we can't do that right now, since the MPC projects that consume IDL files (e.g. AnyTypeCode) reference the individual files, not the IDL project.
- Thus I use an object library.
IDL_FILES_TARGET_SOURCES() calculates absolute paths for CMake, but preserves passing relative paths to tao_idl as required

Considerations before merging

Before merging, I'd like to know if it's possible to fix the TAO_IDL_BE_VIS_* issue. (The targets are completely empty, so CMake complains. I just ~~comment out~~ programmatically delete those 8 lines of $TAO_ROOT/TAO_IDL/CMakeLists.txt. See linked example.)

I'm also wondering if it's possible to generate the three CMake scripts in the appropriate area, maybe when tao_idl is defined. Or potentially be emitted into a ConfigAceTao.cmake module.

ocielliottc · 2023-02-14T12:15:59Z

templates/cmake.mpd

+<%else%>
+<%if(custom_types)%>
+add_library(${PROJECT_TARGET_<%uc(normalize(project_name))%>} OBJECT)
+<%endif%>


What does this do and when does it come into play?

Two things.

First, declaring a compilable target is (currently) required because MPC (currently) emits CMake code that sets several properties of the target ${PROJECT_TARGET_<%uc(normalize(project_name))%>}, including via set_target_properties(), target_compile_definitions(), and target_link_directories(). And currently, no target is declared for custom_types with no library or executable (e.g. IDL). So declaring an object library for custom targets was the smallest change that allowed me to build ACE+TAO. However, I'm not sure if that's "correct" as I don't know the full scope of what custom_types are.

Instead of declaring an object library target, you could conceivably add logic to disable setting those properties for custom_types, but like I said, I don't know what custom_types could be. Perhaps there are custom_types whose output you'd want to compile & link into a library? (I collect my IDL outputs into static or object libraries.)

Second: if tao_idl outputs CPP/H files into the source directory (where all TAO projects expect them), then it's necessary to add those files to some target in the same directory as the CMakeLists.txt that calls tao_idl. (In this case, for simplicity IDL_FILES_TARGET_SOURCES() adds them to the main target of the very file that calls it). If you don't, then CMake does not detect that a command (tao_idl) exists to resolve dependencies on them, and CMake will report missing dependency errors for projects that use them. This prominently happens for AnyTypeCode and PortableServer

Conceivably, IDL_FILES_TARGET_SOURCES() could declare new object library targets for each IDL file, perhaps based on the IDL filename without an extension.

I'm open to recommendations or edits for both points.

Does it require the project that is only a custom_type to create a library? If not, then I'm ok with this change.

I'm not sure entirely what you mean.

Currently, that custom_types object library target is only emitted if the project did not have an executable or (shared or static) library. Do you know whether custom_types projects can ever have those?

I'm asking, what does this line do for the project? In MPC, custom_type only projects do not create libraries.

@alexchandel it may help to define these terms. See MPC's README and html docs for more details.

custom_types is a data structure that can be used in MPC templates. It contains the details of the Define_Custom sections of the input. Typically these are "custom build steps" that run commands (that are not compiling/linking) to generate source files or inputs to other custom build steps.

custom_only is a kind of MPC project that MSVS calls "Utility" -- it doesn't produce object files, a library or an executable, only runs custom build steps.

@mitza-oci This helps. Important question: is it possible to have a custom_types project that is not custom_only? No MPC files in ACE/TAO result in CMakeLists project that has a custom_types plus any other targets (exename, sharedname, or staticname) that I found, but is it possible?

@ocielliottc I've changed the MPC implementation so that custom_types no longer require an object library (and rebased/squashed commits).

The new IDL macro implementation creates a subtarget for individual IDL files, and adds them to a project target (an exe or library) if one exists.

is it possible to have a custom_types project that is not custom_only

If "having a custom_types project" means any project that includes custom generation targets (those files types that are made known to MPC via Define_Custom), then yes this is done quite often in projects that are not custom_only (that is, projects that produce a library or executable).

alexchandel · 2023-02-14T20:16:40Z

I've updated my example implementation to use pure CMake, using a FindAceTao.cmake module. It currently has four hacks, from most to least egregious:

It programmatically deletes the CMakeLists.TAO_IDL_BE_VIS_[A-Z] includes in ${TAO_ROOT}/TAO_IDL/CMakeLists.txt (see OP)
It creates ${ACE_ROOT}/ace/config.h and ${ACE_ROOT}/include/makeinclude/platform_macros.GNU based on templates.
For demonstrative purposes, it uses a hardcoded source release (7.0.11).
It clones this branch of MPC into the source distribution. That could be deleted after this is merged & released, although it also services backwards compatibility.

jwillemsen · 2023-02-15T12:18:21Z

We should have a github action with cmake usage in the mpc project, currently only in ace/tao

jwillemsen

We need a cmake github CI action (see ACE/TAO master) in order to make sure changes here don't break building ACE/TAO

alexchandel · 2023-02-19T20:20:30Z

Just ping me and I'll rebase the PR as needed.

Could someone explain why /TAO/TAO_IDL/GNUmakefile.TAO_IDL_BE_VIS_[ACEIOSUV] exist, but produce empty build files? The hack that FindAceTao.cmake uses to programmatically delete them should be fixed before this is merged.

alexchandel · 2023-02-19T21:43:41Z

We need a cmake github CI action (see ACE/TAO master) in order to make sure changes here don't break building ACE/TAO

I may need help with this. Are you referring to this workflow?

alexchandel · 2023-02-20T03:30:39Z

No idea why MSBuild did this / if it was CMake's fault, but adding a hacky `target_link_directories()` fixes it.

Building the Windows example currently fails to link, with this mystery:

…
Done Building Project "C:\Users\Dev\Git\test-cmake-acetao\build\opt\ACE_wrappers\TAO\orbsvcs\orbsvcs\TAO_CosNotification_Serv.vcxproj" (default targets).

PrepareForBuild:
  Creating directory "TrivialTest.dir\Debug\".
  Creating directory "C:\Users\Dev\Git\test-cmake-acetao\build\Debug\".
  Creating directory "TrivialTest.dir\Debug\TrivialTest.tlog\".
InitializeBuildStatus:
  Creating "TrivialTest.dir\Debug\TrivialTest.tlog\unsuccessfulbuild" because "AlwaysCreate" was specified.
CustomBuild:
  Building Custom Rule C:/Users/Dev/Git/test-cmake-acetao/CMakeLists.txt
ClCompile:
  C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.29.30133\bin\HostX64\x64\CL.exe /c /I"C:\Users\Dev\Git\test-cmake-acetao\opt\ACE_wrappers" /I"C:\Users\Dev\Git\test-cmake-acetao\opt\ACE_wrappers\TAO" /I"C:\Users\Dev\Git\test-cmake-acetao\opt\ACE_wrappers\TAO\orbsvcs" /Zi /nologo /W1 /WX- /diagnostics:column /Od /Ob0 /D _MBCS /D WIN32 /D _WINDOWS /D "MPC_LIB_MODIFIER=\"d\"" /D TAO_HAS_VALUETYPE_OUT_INDIRECTION /D TAO_HAS_TYPED_EVENT_CHANNEL /D "CMAKE_INTDIR=\"Debug\"" /Gm- /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /Fo"TrivialTest.dir\Debug\\" /Fd"TrivialTest.dir\Debug\vc142.pdb" /external:W1 /Gd /TP /errorReport:queue "C:\Users\Dev\Git\test-cmake-acetao\main.cpp"
  main.cpp
Link:
  C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.29.30133\bin\HostX64\x64\link.exe /ERRORREPORT:QUEUE /OUT:"C:\Users\Dev\Git\test-cmake-acetao\build\Debug\TrivialTest.exe" /INCREMENTAL /ILK:"TrivialTest.dir\Debug\TrivialTest.ilk" /NOLOGO "C:\Users\Dev\Git\test-cmake-acetao\opt\ACE_wrappers\lib\ACEd.lib" "C:\Users\Dev\Git\test-cmake-acetao\opt\ACE_wrappers\lib\ACE_ETCLd.lib" "C:\Users\Dev\Git\test-cmake-acetao\opt\ACE_wrappers\lib\ACE_ETCL_Parserd.lib" "C:\Users\Dev\Git\test-cmake-acetao\opt\ACE_wrappers\lib\TAOd.lib" "C:\Users\Dev\Git\test-cmake-acetao\opt\ACE_wrappers\lib\TAO_AnyTypeCoded.lib" "C:\Users\Dev\Git\test-cmake-acetao\opt\ACE_wrappers\lib\TAO_CodecFactoryd.lib" "C:\Users\Dev\Git\test-cmake-acetao\opt\ACE_wrappers\lib\TAO_CosConcurrencyd.lib" "C:\Users\Dev\Git\test-cmake-acetao\opt\ACE_wrappers\lib\TAO_CosEventd.lib" "C:\Users\Dev\Git\test-cmake-acetao\opt\ACE_wrappers\lib\TAO_CosEvent_Servd.lib" "C:\Users\Dev\Git\test-cmake-acetao\opt\ACE_wrappers\lib\TAO_CosEvent_Skeld.lib" "C:\Users\Dev\Git\test-cmake-acetao\opt\ACE_wrappers\lib\TAO_CosNamingd.lib" "C:\Users\Dev\Git\test-cmake-acetao\opt\ACE_wrappers\lib\TAO_CosNaming_Servd.lib" "C:\Users\Dev\Git\test-cmake-acetao\opt\ACE_wrappers\lib\TAO_CosNaming_Skeld.lib" "C:\Users\Dev\Git\test-cmake-acetao\opt\ACE_wrappers\lib\TAO_CosNotificationd.lib" "C:\Users\Dev\Git\test-cmake-acetao\opt\ACE_wrappers\lib\TAO_CosNotification_Servd.lib" "C:\Users\Dev\Git\test-cmake-acetao\opt\ACE_wrappers\lib\TAO_CosNotification_Skeld.lib" "C:\Users\Dev\Git\test-cmake-acetao\opt\ACE_wrappers\lib\TAO_DynamicAnyd.lib" "C:\Users\Dev\Git\test-cmake-acetao\opt\ACE_wrappers\lib\TAO_DynamicInterfaced.lib" "C:\Users\Dev\Git\test-cmake-acetao\opt\ACE_wrappers\lib\TAO_ETCLd.lib" "C:\Users\Dev\Git\test-cmake-acetao\opt\ACE_wrappers\lib\TAO_IFR_Clientd.lib" "C:\Users\Dev\Git\test-cmake-acetao\opt\ACE_wrappers\lib\TAO_IORTabled.lib" "C:\Users\Dev\Git\test-cmake-acetao\opt\ACE_wrappers\lib\TAO_Messagingd.lib" "C:\Users\Dev\Git\test-cmake-acetao\opt\ACE_wrappers\lib\TAO_PId.lib" "C:\Users\Dev\Git\test-cmake-acetao\opt\ACE_wrappers\lib\TAO_PortableServerd.lib" "C:\Users\Dev\Git\test-cmake-acetao\opt\ACE_wrappers\lib\TAO_Svc_Utilsd.lib" "C:\Users\Dev\Git\test-cmake-acetao\opt\ACE_wrappers\lib\TAO_Valuetyped.lib" iphlpapi.lib TAO_IFR_Clientd.lib TAO_DynamicInterfaced.lib TAO_IORTabled.lib TAO_CosNaming_Skeld.lib TAO_CosNamingd.lib ACE_ETCL_Parserd.lib TAO_ETCLd.lib TAO_DynamicAnyd.lib TAO_CosNotification_Skeld.lib TAO_Svc_Utilsd.lib TAO_CosEvent_Skeld.lib TAO_CosNotificationd.lib TAO_CosEventd.lib TAO_Messagingd.lib ACE_ETCLd.lib TAO_PId.lib TAO_Valuetyped.lib TAO_CodecFactoryd.lib TAO_PortableServerd.lib TAO_AnyTypeCoded.lib TAOd.lib ACEd.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed /DEBUG /PDB:"C:/Users/Dev/Git/test-cmake-acetao/build/Debug/TrivialTest.pdb" /SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:"C:/Users/Dev/Git/test-cmake-acetao/build/Debug/TrivialTest.lib" /MACHINE:X64  /machine:x64 TrivialTest.dir\Debug\main.obj
LINK : fatal error LNK1104: cannot open file 'TAO_IFR_Clientd.lib' [C:\Users\Dev\Git\test-cmake-acetao\build\TrivialTest.vcxproj]
Done Building Project "C:\Users\Dev\Git\test-cmake-acetao\build\TrivialTest.vcxproj" (default targets) -- FAILED.

Done Building Project "C:\Users\Dev\Git\test-cmake-acetao\build\ALL_BUILD.vcxproj" (default targets) -- FAILED.


Build FAILED.

"C:\Users\Dev\Git\test-cmake-acetao\build\ALL_BUILD.vcxproj" (default target) (1) ->
"C:\Users\Dev\Git\test-cmake-acetao\build\TrivialTest.vcxproj" (default target) (3) ->
"C:\Users\Dev\Git\test-cmake-acetao\build\opt\ACE_wrappers\TAO\tao\CodecFactory\TAO_CodecFactory.vcxproj" (default target) (13) ->
(CustomBuild target) ->
  C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(241,5): warning MSB8065: Custom build for item "C:\Users\Dev\Git\test-cmake-acetao\opt\ACE_wrappers\TAO\tao\CodecFactory\IOP_Codec.pidl" succeeded, but specified output "c:\users\dev\git\test-cmake-acetao\build\opt\ace_wrappers\tao\tao\codecfactory" has not been created. This may cause incremental build to work incorrectly. [C:\Users\Dev\Git\test-cmake-acetao\build\opt\ACE_wrappers\TAO\tao\CodecFactory\TAO_CodecFactory.vcxproj]


"C:\Users\Dev\Git\test-cmake-acetao\build\ALL_BUILD.vcxproj" (default target) (1) ->
"C:\Users\Dev\Git\test-cmake-acetao\build\TrivialTest.vcxproj" (default target) (3) ->
"C:\Users\Dev\Git\test-cmake-acetao\build\opt\ACE_wrappers\TAO\orbsvcs\orbsvcs\TAO_CosEvent_Serv.vcxproj" (default target) (16) ->
"C:\Users\Dev\Git\test-cmake-acetao\build\opt\ACE_wrappers\TAO\tao\IFR_Client\TAO_IFR_Client.vcxproj" (default target) (25) ->
  C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(241,5): warning MSB8065: Custom build for item "C:\Users\Dev\Git\test-cmake-acetao\opt\ACE_wrappers\TAO\tao\IFR_Client\IFR_Base.pidl" succeeded, but specified output "c:\users\dev\git\test-cmake-acetao\build\opt\ace_wrappers\tao\tao\ifr_client" has not been created. This may cause incremental build to work incorrectly. [C:\Users\Dev\Git\test-cmake-acetao\build\opt\ACE_wrappers\TAO\tao\IFR_Client\TAO_IFR_Client.vcxproj]


"C:\Users\Dev\Git\test-cmake-acetao\build\ALL_BUILD.vcxproj" (default target) (1) ->
"C:\Users\Dev\Git\test-cmake-acetao\build\TrivialTest.vcxproj" (default target) (3) ->
"C:\Users\Dev\Git\test-cmake-acetao\build\opt\ACE_wrappers\TAO\orbsvcs\orbsvcs\TAO_CosNaming_Serv.vcxproj" (default target) (26) ->
"C:\Users\Dev\Git\test-cmake-acetao\build\opt\ACE_wrappers\TAO\tao\IORTable\TAO_IORTable.vcxproj" (default target) (28) ->
  C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(241,5): warning MSB8065: Custom build for item "C:\Users\Dev\Git\test-cmake-acetao\opt\ACE_wrappers\TAO\tao\IORTable\IORTable.pidl" succeeded, but specified output "c:\users\dev\git\test-cmake-acetao\build\opt\ace_wrappers\tao\tao\iortable" has not been created. This may cause incremental build to work incorrectly. [C:\Users\Dev\Git\test-cmake-acetao\build\opt\ACE_wrappers\TAO\tao\IORTable\TAO_IORTable.vcxproj]


"C:\Users\Dev\Git\test-cmake-acetao\build\ALL_BUILD.vcxproj" (default target) (1) ->
"C:\Users\Dev\Git\test-cmake-acetao\build\TrivialTest.vcxproj" (default target) (3) ->
(Link target) ->
  LINK : fatal error LNK1104: cannot open file 'TAO_IFR_Clientd.lib' [C:\Users\Dev\Git\test-cmake-acetao\build\TrivialTest.vcxproj]

    3 Warning(s)
    1 Error(s)

No idea why. C:\Users\Dev\Git\test-cmake-acetao\opt\ACE_wrappers\lib\TAO_IFR_Clientd.lib exists, but I'm not sure why TAO_IFR_Clientd is passed twice to the linker.

It could be a coincidence, but CMake generation on unix also prints a couple warnings about IFR_Client when building it, however everything links correct in the end:

[ 97%] Built target TAO_DynamicInterface
opt/ACE_wrappers/TAO/tao/IFR_Client/CMakeFiles/TAO_IFR_Client.dir/build.make:94: warning: overriding commands for target `opt/ACE_wrappers/TAO/tao/IFR_Client'
opt/ACE_wrappers/TAO/tao/IFR_Client/CMakeFiles/TAO_IFR_Client.dir/build.make:82: warning: ignoring old commands for target `opt/ACE_wrappers/TAO/tao/IFR_Client'
opt/ACE_wrappers/TAO/tao/IFR_Client/CMakeFiles/TAO_IFR_Client.dir/build.make:94: warning: overriding commands for target `opt/ACE_wrappers/TAO/tao/IFR_Client'
opt/ACE_wrappers/TAO/tao/IFR_Client/CMakeFiles/TAO_IFR_Client.dir/build.make:82: warning: ignoring old commands for target `opt/ACE_wrappers/TAO/tao/IFR_Client'
[ 97%] Built target TAO_IFR_Client

alexchandel · 2023-02-20T07:45:56Z

Example IDL generation was updated to fix IDL projects with *export.h on Windows.

One thing to resolve on Windows / MSVC. Three TAO IDL projects (`CodecFactory`, `IFR_Client`, and `IORTable`) repeatedly regenerate their sources and rebuild on every `cmake --build` invocation, each with a similar warning referencing a nonexistent target:

  …
  ACE_ETCL.vcxproj -> C:\Users\Dev\Git\vplk\opt\ACE_wrappers\lib\ACE_ETCLd.dll
  ACE_ETCL_Parser.vcxproj -> C:\Users\Dev\Git\vplk\opt\ACE_wrappers\lib\ACE_ETCL_Parserd.dll
  Generating C:/Users/Dev/Git/vplk/opt/ACE_wrappers/TAO/tao/CodecFactory/IOP_CodecC.h, ., C:/Users/Dev/Git/vplk/opt/ACE_wrappers/TAO/tao/CodecFactory/IOP_CodecS.h, C:/Users/Dev/Git/vplk/opt/ACE_wrappers/TAO/tao/CodecFactory/IOP_CodecA.h, C:/Users/Dev/Git/vplk/opt/ACE_wrappers/TAO/tao/CodecFactory/IOP_CodecC.cpp tao-idli_4xRhFS.cpp
C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(241,5): warning MSB8065: Custom build for item "C:\Users\Dev\Git\vplk\opt\ACE_wrappers\TAO\tao\CodecFactory\IOP_Codec.pidl" succeeded, but specified output "c:\users\dev\git\vplk\build\opt\ace_wrappers\tao\tao\codecfactory" has not been created. This may cause incremental build to work incorrectly. [C:\Users\Dev\Git\vplk\build\opt\ACE_wrappers\TAO\tao\CodecFactory\TAO_CodecFactory.vcxproj]
  CDR_Encaps_Codec.cpp
  CodecFactory.cpp
  CodecFactory_impl.cpp
  IOP_CodecC.cpp
  IOP_Codec_includeC.cpp
  Generating Code...
  TAO_CodecFactory.vcxproj -> C:\Users\Dev\Git\vplk\opt\ACE_wrappers\lib\TAO_CodecFactoryd.dll
  TAO_CosEvent_Skel.vcxproj -> C:\Users\Dev\Git\vplk\opt\ACE_wrappers\lib\TAO_CosEvent_Skeld.dll
  …

What's different about these three libraries?

jwillemsen · 2023-02-20T08:17:47Z

We need a cmake github CI action (see ACE/TAO master) in order to make sure changes here don't break building ACE/TAO

I may need help with this. Are you referring to this workflow?

Yes

mitza-oci · 2023-02-20T15:05:46Z

Could someone explain why /TAO/TAO_IDL/GNUmakefile.TAO_IDL_BE_VIS_[ACEIOSUV] exist, but produce empty build files? The hack that FindAceTao.cmake uses to programmatically delete them should be fixed before this is merged.

They are not empty in static builds. It seems like they were added to work around some platform limit on the size (in objects or symbols or ??) of archive libraries on that platform.

It is reasonable to consider removing that workaround. But that's not part of the MPC repository - please create an issue or PR in ACE_TAO.

alexchandel · 2023-02-25T04:32:21Z

@mitza-oci Ok, I will also try to edit the CMake generation to account for them then. My goal is to provide retroactive support for valid MPC files & ACE+TAO versions (hence I included checks for post-7.0.11 ACE+TAO in FindAceTao.cmake), so if they are valid MPC, the generated CMake should not error.

alexchandel · 2023-02-27T19:50:27Z

How does one enable SSL or IPv6 when generating from MPC? I see that the MPC files in /ace/SSL/ get included by TAO_ACE.mwc, but report that ssl and ace_for_tao are required (and ace_for_tao.mpc also requires ace_for_tao). It is as simple as invoking MPC with -features=ssl,ace_for_tao?

Generating 'cmake' output using TAO_ACE.mwc
Skipping ACE_XML_Utils (XML.mpc); it requires xerces.
Skipping ACE_FlReactor (ace_flreactor.mpc); it requires fl.
Skipping ACE_FOR_TAO (ace_for_tao.mpc); it requires ace_for_tao.
Skipping ACE_Qt5Reactor_moc (ace_qt5reactor.mpc); it requires qt5.
Skipping ACE_Qt5Reactor (ace_qt5reactor.mpc); it requires qt5.
Skipping ACE_Qt4Reactor_moc (ace_qt4reactor.mpc); it requires qt4.
Skipping ACE_Qt4Reactor (ace_qt4reactor.mpc); it requires qt4.
Skipping ACE_XtReactor (ace_xtreactor.mpc); it requires xt.
Skipping ACE_TkReactor (ace_tkreactor.mpc); it requires tk.
Skipping QoS (qos.mpc); it requires qos.
Skipping ace_svcconf_gen (svcconfgen.mpc); it requires ace_svcconf_gen.
Skipping ACE_FoxReactor (ace_foxreactor.mpc); it requires fox.
Skipping SSL (ssl.mpc); it requires ssl.
Skipping SSL_FOR_TAO (ssl_for_tao.mpc); it requires ssl.
Skipping INet_SSL (inet_ssl.mpc); it requires ssl.
Skipping TAO_XtResource (XtResource.mpc); it requires xt.
Skipping TAO_TkResource (TkResource.mpc); it requires tk.
Skipping Bzip2Compressor (Bzip2Compressor.mpc); it requires bzip2.
Skipping LzoCompressor (LzoCompressor.mpc); it requires lzo1.
Skipping ZlibCompressor (ZlibCompressor.mpc); it requires zlib.
Skipping TAO_QtResource (QtResource.mpc); it requires dummy_label.
Skipping TAO_FlResource (FlResource.mpc); it requires fl.
Skipping TAO_FoxResource (FoxResource.mpc); it requires fox.
Skipping TAO_IDL_GEN (tao_idl_fe.mpc); it requires tao_idl_fe_gen.
Skipping wxNamingViewer (wxNamingViewer.mpc); it requires wxWindows.
Skipping NamingViewer (NamingViewer.mpc); it requires mfc.
Skipping SSLIOP (SSLIOP.mpc); it requires ssl.

ocielliottc · 2023-02-27T19:57:54Z

You can either modify $ACE_ROOT/bin/MakeProjectCreator/default.features and add the line:

ssl=1

or

You can add them to your MPC command line: -features ssl=1

The ace_for_tao feature isn't required to use SSL.

Do not generate target properties if custom_only. Add headers and inline files to compiled targets. Supply correct target names for linking libraries.

alexchandel · 2023-03-02T00:56:01Z

I rewrote the commits to fix a bug with linking and installation, and another with out-of-source builds. I've also updated my reference implementation of FindAceTao.cmake and idl_files.cmake to reflect these.

With the reference implementation (and its TAO_IDL_BE_VIS_[ACEIOSUV] workaround), I believe ACE+TAO 7.0.11 (and later, and possibly earlier) now builds and installs properly and idiomatically with CMake on Windows & macOS. Linux and features like ssl next.

alexchandel · 2023-03-02T01:39:53Z

Where in the ACE+TAO MPC configuration do you define the version of the C++ standard that the ACE+TAO source currently requires?

I currently have to manually add C++11:

    target_compile_features(ACE PUBLIC cxx_std_11)
    target_compile_features(TAO PUBLIC cxx_std_11)

iguessthislldo · 2023-03-02T08:19:00Z

Where in the ACE+TAO MPC configuration do you define the version of the C++ standard that the ACE+TAO source currently requires?

I'm don't think there's a place where MPC itself is concerned with that. As far as I know it's assumed until checked here (Note: it was C++11 until recently). These macros come from the platform config files like this one for g++. So to have a proper CMake check probably requires manually injecting it in the ace.mpc.

alexchandel · 2023-03-02T21:25:40Z

@iguessthislldo I would argue that the minimum C++ standard required by the source is something the MPC project files should be concerned with and declare, as the compiler must be told by the build system which version to use. MPC shouldn't just assume the compiler will use the latest standard it can (and compilers do not generally, as each C++ standard introduces many breaking changes).

And after all, 7.0.12's source will now error if the standard less than C++14. So the MPC project file should declare a minimum standard for the source, so users and build systems don't have to do this manually.

mitza-oci · 2023-03-02T21:28:28Z

@iguessthislldo I would argue that the minimum C++ standard required by the source is something the MPC project files should be concerned with and declare, as the compiler must be told by the build system which version to use.

MPC shouldn't just assume the compiler will use the latest standard it can (and compilers do not generally, as each C++ standard introduces many breaking changes).

MPC is not assuming that.

And after all, 7.0.12's source will now error if the standard less than C++14. So the MPC project file should declare a minimum standard for the source, so users and build systems don't have to do this manually.

This is not what MPC does. MPC generates projects and has a number of mechanisms for customizing those projects, it's not a complete configuration system like CMake.

jwillemsen requested a review from ocielliottc February 14, 2023 07:20

ocielliottc reviewed Feb 14, 2023

View reviewed changes

jwillemsen requested changes Feb 19, 2023

View reviewed changes

alexchandel mentioned this pull request Feb 24, 2023

[request] adopt vscode-mpc under DOCGroup #180

Closed

alexchandel force-pushed the cmake-idl branch 2 times, most recently from dfc892d to 773e158 Compare February 27, 2023 06:15

alexchandel added 2 commits March 1, 2023 17:56

CMake: Fix custom targets, header deps, and debug linking

fc5bc00

Do not generate target properties if custom_only. Add headers and inline files to compiled targets. Supply correct target names for linking libraries.

CMake: Fix out-of-source builds

6f663b0

alexchandel force-pushed the cmake-idl branch from 773e158 to 6f663b0 Compare March 2, 2023 00:17

alexchandel mentioned this pull request Jul 30, 2023

TAO::TAO_CO_THRU_POA_STRATEGY bit missing from CosEventChannelAdmin::EventChannel->for_suppliers(), causing it to throw CORBA system exception DOCGroup/ACE_TAO#2091

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

CMake support to build ACE+TAO including IDL targets #177

CMake support to build ACE+TAO including IDL targets #177

CMake support to build ACE+TAO including IDL targets #177

Are you sure you want to change the base?

CMake support to build ACE+TAO including IDL targets #177

Conversation

Key changes:

Considerations that went into this:

Considerations before merging

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment