Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature/new Bindings generator #946

Merged
merged 71 commits into from
Aug 21, 2019
Merged

Conversation

realvictorprm
Copy link
Contributor

@realvictorprm realvictorprm commented Aug 11, 2019

Replace binder with a rewritten modern variant

The old binder does not work for the new specification. This PR aims to provide a completely new written version using ADL for xplatform native calls. The generator will be completely written in F# as it's best suited for this task.

Testing status

Tests will just verify the transformations and filtering done during the generation process

Comments

This has been decided after a long conversation with Fred, jvbl and Varon with me.

@NogginBops
Copy link
Member

NogginBops commented Aug 11, 2019

Is writing the generator in F# really a good idea?

Almost the entire project is written in C# and it is expected that only C# developers would be interested in contributing to this project. That means that we cannot expect future contributors to have extensive knowledge in F#. So if we write the entire bindings in F# we are in a situation where future maintainers might not be able to use the generator anymore because there is no-one left who knows anything about F#.

I'm sorry to say but this does not feel like it is a good idea in the long-term (maybe even the short term as it will take longer to complete and fewer contributors can contribute). Especially looking a the history of this project (changing maintainers and contributors a lot) it feels like this is not the move we want to make.

Sorry to revive the discussion @realvictorprm @varon @jvbsl :)

@varon
Copy link
Member

varon commented Aug 12, 2019

@realvictorprm - Looking good so far.

Can we avoid committing the gl4.xml ? Would be ideal if we could manage it as a dependency using the locked commit ID as part of the build process.

@varon varon changed the title Feature/new generator [WIP] Feature/new Bindings generator Aug 12, 2019
@realvictorprm
Copy link
Contributor Author

realvictorprm commented Aug 12, 2019 via email

build.fsx Outdated
|> Seq.concat
|> Seq.toList

let testAssemblies = "tests/**/obj/Release/*Tests*.dll"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These should not be taken from the obj folder, but bin/Release

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @deccer. We really appreciate ad-hoc reviews and such!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that makes much more sense lol, thanks a lot

build.fsx Outdated Show resolved Hide resolved

// Generate assembly info files with the right version & up-to-date information
Target.create "AssemblyInfo" (fun _ ->
//TODO: Create and update the Directory.Build.props file with the version information taken from the releaseNotes value.
Copy link
Contributor

@deccer deccer Aug 12, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe could be turned into an issue in a Project Build System? (Edit: I was referring to the TODO line)

build.fsx Outdated
// This preserves subdirectories.
Target.create "CopyBinaries" (fun _ ->
releaseProjects
|> Seq.map (fun f -> ((System.IO.Path.GetDirectoryName f) @@ "bin/Release/netstandard2.0", "bin" @@ (System.IO.Path.GetFileNameWithoutExtension f)))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense, to put that in a variable, for easier maintenance..... /netstandard2.0 i mean (Im not sure if the review thing here, keeps the thing i marked)

build.fsx Outdated

let testAssemblies = "tests/**/obj/Release/*Tests*.dll"

let nugetCommandRunnerPath = ".fake/build.fsx/packages/NuGet.CommandLine/tools/NuGet.exe" |> Fake.IO.Path.convertWindowsToCurrentPath
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe move the nuget.exe path into a variable on top of the script as well

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll see later if I can remove it, to my memory I think I can remove it...

build.fsx Outdated
!! "tests/**/*.??proj"

let allProjects =
[toolProjects ; releaseProjects; testProjects ]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

me being picky here, run a Format Document over the files please :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will run Fantomas later

src/Generator/Program.fs Outdated Show resolved Hide resolved
src/Generator/Program.fs Outdated Show resolved Hide resolved
src/Generator/Program.fs Outdated Show resolved Hide resolved
src/Generator/Program.fs Outdated Show resolved Hide resolved
src/Generator/Program.fs Outdated Show resolved Hide resolved
src/Generator/Program.fs Outdated Show resolved Hide resolved
src/binding/Binding/Initializer.cs Outdated Show resolved Hide resolved
src/binding/Binding/Initializer.cs Outdated Show resolved Hide resolved
src/binding/Binding/Types.cs Outdated Show resolved Hide resolved
@frederikja163
Copy link
Member

Is writing the generator in F# really a good idea?

Almost the entire project is written in C# and it is expected that only C# developers would be interested in contributing to this project. That means that we cannot expect future contributors to have extensive knowledge in F#. So if we write the entire bindings in F# we are in a situation where future maintainers might not be able to use the generator anymore because there is no-one left who knows anything about F#.

I'm sorry to say but this does not feel like it is a good idea in the long-term (maybe even the short term as it will take longer to complete and fewer contributors can contribute). Especially looking a the history of this project (changing maintainers and contributors a lot) it feels like this is not the move we want to make.

Sorry to revive the discussion @realvictorprm @varon @jvbsl :)

Just for future reference, we gave the response over discord
https://discordapp.com/channels/337627185248468993/525453014618865664/610432160389791763

src/Generator/Program.fs Outdated Show resolved Hide resolved
src/Generator/Program.fs Outdated Show resolved Hide resolved
src/Generator/Program.fs Outdated Show resolved Hide resolved
@Kavignon
Copy link

Let's keep the history clean! Whenever there's an in-progress investigation/implementation, it's ok to do as many commits as possible. But when done, squash them into one which sums up the work done to finish solving the problem :)

@realvictorprm
Copy link
Contributor Author

realvictorprm commented Aug 19, 2019 via email

@Kavignon
Copy link

Then potentially we should remove the CE for maybe since it's not being used in your implementation?

@realvictorprm
Copy link
Contributor Author

realvictorprm commented Aug 19, 2019 via email

@frederikja163 frederikja163 mentioned this pull request Aug 20, 2019
@@ -76,6 +78,8 @@ let autoGenerateAdditionalOverloadForType (func: PrintReadyTypedFunctionDeclarat
let (genericName, newParameterType) =
currParameter.typ.typ
|> transformPointerTy i tyMapper
// Yes this is a bit evil, I'm sorry but this was easiest here.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this evil?

@varon varon merged commit 7b036e5 into opentk:master Aug 21, 2019
@varon
Copy link
Member

varon commented Aug 21, 2019

Thanks so much for this amazing PR, @realvictorprm .

It's a huge, huge contribution and helps set up the project and move it forward in the most amazing way. Special Thanks from everyone at OpenTK!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants