Auto Project generation / NLog / relocation of tests project

[Hecatron]

Hi there,

I'm thinking of making a couple of changes / pull requests for QtSharp and just wanted to get some feedback before going ahead

1. NLog Support The first thing I was thinking about was adding a reference to NLog (via a NuGet packages file) then replacing the log messages with calls to Nlog instead by default the output to the console would be the same as is but you'd have the option of filtering the output to particular class's or message levels via a config file for debugging (informational / error etc). also it's possible to feed the messages into an external app for easier viewing / filtering
   Most of the console output is actually done by CppSharp, but I figured it'd be a good starting point to add it here first if that's okay
2. Relocation of tests project I was thinking it might be best to create a Tests sub directory, then move / relocate the existing QtSharp.Tests project into there, and rename it QtSharp.Tests.QtCore, then have a seperate test project for each QtModule, that way it's filterable within Visual Studio once we have more tests for more modules. Would this be okay?
3. Auto Project FIle Generation I kind of assumed initially the project files would be pulled from the repo and just the code for the Qt Modules would be auto generated, but it looks instead the project files under wrappers need to be auto generated based on the below https://github.com/ddobrev/QtSharp/pull/29#issuecomment-80656214 https://github.com/ddobrev/QtSharp/issues/8#issuecomment-56527581
   The question I've got is: Which would be the best method to generate the project files?
   One approach is to use premake, this way we just generate a text file to feed into premake, an option if to generate visual studio or make files, then run that Another approach is to use the inbuilt .Net class's to try and generate the project files, but that's probably less cross platform and I'm not sure off hand how to generate Makefiles from within .Net without a lot of work

My preference would write a couple of class's to generate files for / use premake, would this be okay?

[ddobrev]

@grbd let's start with the logging. Since the issue is not Qt#-specific, @tritao will join us. Personally, I don't mind NLog, however, if we're going to integrate it, it has to be in C++#, not in Qt#.

[ddobrev]

@grbd could you give some e-mail so that we can exchange Skype id-s? We'd discuss it much faster that way.

[Hecatron]

I've just ordered an adapter for my headset, so I'll get back to you when that arrives

So far I've setup a linux vm for testing, if I'm changing cppsharp I'll need to make sure any changes are cross platform. Also once I have skype sorted, I might ask about moving from premake to cmake for the generation of project files etc. I'm trying to figure out the best option for using Nuget across different platforms at the moment (for my own projects as well)

[tritao]

Why do you feel the need to change project generation from Premake to CMake?

At least for C++# that won't be an option, we've put a lot of effort over the years on contributing features and fixes to Premake to properly deal with our mixed C++/C# codebase. I don't think CMake has very good support for C#.

[Hecatron]

I don't now, I was just looking for a way to get NuGet to work in an automatic fashion under Linux (I assumed initially cmake might already have a script setup for it) I've tried the bootstrap version of NuGet recently on the latest kubuntu and it seems to work fine and it's very simple to run, so calling it from a lua script should be okay

What would your thoughts be on including NuGet.exe within the build directory along side Premake.exe?. For the auto download of depends such as NUnit / NLog

QtSharp already has one project dependent on NUnit which is downloaded via NuGet but I get the impression later on the project files might be auto generated in the same way they are for CppSharp.

Considering CppSharp throws out quite a lot of log messages, I was thinking it would be usefull to pipe them via NLog so that by default it's the same as is now, but you could customise the log output using a NLog config file into an external app or other destination, and filter it by class / log level etc.

[ddobrev]

I am little familiar with NLog and I've had little use of logging in the project, so you two can count be as neutral in this matter. Please decide about this point yourselves.

[Hecatron]

Closing down for now