Multiple sln and csproj files
Closed this issue · 6 comments
I was wondering, why are multiple sln and csproj files used instead of multiple configurations? In example, WIN32 is defined when using the normal slns. This could be moved to having Debug and DebugMono configurations for example, and each project would define WIN32 (for ConsoleFramework.csproj) for Debug, and not define it for DebugMono. It would make things way cleaner.
This would help with syncing projects and solutions automatically.
Is there anything else different than that define?
Okay, I got a better solution. We don't even need multiple configurations. You use Mono.Unix just to do a systemcall, which can be solved doing a PInvoke.
We can import static extern int uname (IntPtr buf) from libc and do a Marshal.PtrToStringAnsi on the result.
If you're okay with this idea, I can work on doing a single csproj/sln, with the advantage of removing the dependency on Mono.Posix.
Okay, I'm not sure how to solve the signal trapping atm, but there should be a solution for that too.
I think it is impossible to find a really good way ) One idea I had was to write some script to generate two sln files from sources structure (because sln is just for IDE, for building there is nant tool). But now mono solution is outdated and I need to synchronize it manually. I think it is not so serious problem, but, if you will propose a better way, I will try it :)
Okay, so I don't know how to get rid of the UnixSignal dependency, and that means Mono.Posix. The sln and csproj thing can be fixed though:
- Have a Debug and DebugMono configuration in which different constants are defined for ConsoleFramework, the rest seem to be 100% the same from a csproj level.
- This could be improved by using a
Condition=" '$(Configuration)' " == 'DebugMono' "construct.
And ta-da, the mess should be gone.
It works !!! Wow !