thrift-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mario Emmenlauer (Jira)" <j...@apache.org>
Subject [jira] [Commented] (THRIFT-5169) Improve dotnet project files for the .NET Standard build, and integrate with cmake
Date Tue, 05 May 2020 10:35:00 GMT

    [ https://issues.apache.org/jira/browse/THRIFT-5169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17099761#comment-17099761
] 

Mario Emmenlauer commented on THRIFT-5169:
------------------------------------------

Yes, this is what I currently use with cmake, and this is the "problem" I have with `Makefile.am`.
In the cmake build, I use dotnet for example in `lib/netstd/CMakeLists.txt` in the following
way:
{code}
add_custom_target(ThriftNetSTD ALL
    COMMENT "Building Thrift NetSTD with dotnet"
    DEPENDS copy-thrift-compiler
    COMMAND "${DOTNET_EXE}" msbuild "Thrift.csproj"
        /nologo /restore /target:Rebuild
        "/property:Configuration=${CMAKE_BUILD_TYPE}"
        "/property:OutDir=${CMAKE_CURRENT_BINARY_DIR}/Thrift/bin"
        "/property:BaseIntermediateOutputPath=${CMAKE_CURRENT_BINARY_DIR}/Thrift/obj/"
    WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}/Thrift/")
{code}

The most relevant parameter is `/property:OutDir`. This corresponds to the `--output` switch
that you mention.

To progress with the build, I would need to pass the same option in the Makefile.am. And here
is the catch: I don't know what `OutDir` is in autotools. In cmake, I set this to the current
temporary build directory (aka `${CMAKE_CURRENT_BINARY_DIR}/Thrift/bin`). Subsequent calls
to dotnet will find the assemblies in this directory during build time, and later they will
be installed to TARGETDIR from this directory.

Are there autotools-variables that correspond to `${CMAKE_CURRENT_BINARY_DIR}`?

> Improve dotnet project files for the .NET Standard build, and integrate with cmake
> ----------------------------------------------------------------------------------
>
>                 Key: THRIFT-5169
>                 URL: https://issues.apache.org/jira/browse/THRIFT-5169
>             Project: Thrift
>          Issue Type: Improvement
>          Components: netstd - Library
>    Affects Versions: 0.13.0
>            Reporter: Mario Emmenlauer
>            Assignee: Mario Emmenlauer
>            Priority: Minor
>
> I'm working on a number of improvements for the .NET Standard Visual Studio project
files. Currently it seems to me that the following changes are required:
>  * I can not use the detection of the thrift compiler using the section {{<Exec Condition="'$(OS)'
== 'Windows_NT'" Command="where thrift" ConsoleToMSBuild="true">}} because it breaks the
build for me. But I am also under the impression that this is not clean by design. Autotools
place the thrift compiler into a specific directory, and I've modified the cmake build to
also do that. I think this is sensible, that all tutorials and tests use *only* the thrift
compiler from the current build, and fail otherwise. This seems sensible because any other
system-installed thrift compiler may behave different and may not lead to the desired result
of tests/tutorials, which becomes very hard to debug with the auto-detection mechanism.
>  * The Visual Studio project files for the tests and tutorial currently all reference
the project file of the Thrift library. This breaks the build for me because the thrift build
is using .NET Standard 2.0, whereas all consumers are (in my eyes correctly) using .NET Core
3.1. I can not mix and mingle the different .NET platforms due to hard-to-resolve errors with
dependency ambiguities. However there seems to be a much cleaner solution: Instead of referencing
the thrift library project file, it is possible to reference the Thrift.dll assembly. This
is how an external consumer of the library would be implemented, so it is closer to the real
world use case. Additionally it has the benefit to work with different .NET platforms without
dependency issues.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Mime
View raw message