[CMake] cmake analogue - syncProj visual studio generation tool

Sat Mar 31 12:08:16 EDT 2018

Hi !
> Reading this on the CMake mailing list I am first of all asking myself: Why should I go for such a certainly nice alternative if I already have CMake?
Basically once new tool is created,  tool establish it's own community around it - and like with religion, it's difficult to turn religious people around or convince them to use other tool. 
Key advantage of syncProj, is that as scripting language youwill use full dialect of C# - that means you can read / write files using normal C# language, you can probe anything you want,from files or from registry, and you have built-in RegEx if you need to parse or extract anything what is needed.Also any version file generation, or any file generation is also relatively simple - use StringBuilder (C#, built-in).Xml or Json parsing is also simple, also built in.
But I think main key advantage over cmake is ability to debug project generation script itself, and having full supportfor intellisense (offered by Visual studio).
> On the other hand: Just think about the fact that CMake is indeed Open Source!
Also syncProj is fully open source code - I haven't placed any license, but I will add MIT license later on.
> In other words: Standing on the shoulders of a giant gives you a phantastic view and lets you feel like you are a giant yourself! ;-)> So in short: Thanks for the free offer, but I don't need it because I have CMake!

I would prefer to avoid using different associations or getting emotional in this chat. syncProj is a small tool, my own prototype.Even thus it's small, it can do much more already what cmake cannot do.
Want to use it - use it, don't want to use it - then don't use it. It's a simple like that.
I would prefer not to fight against cmake, but maybe check what we could have in common (maybe unit / integration testing ?).My vision is to have C++ as a base code in syncProj, but I will probably need C++ 2018 - ... features. 
-- Have a nice day!     Tarmo.

      From: Cornelis Bockemühl <cornelis at bockemuehl.ch>
 To: Tarmo Pikaro <tapika at yahoo.com>; "cmake at cmake.org" <cmake at cmake.org> 
 Sent: Saturday, March 31, 2018 12:02 PM
 Subject: Re: [CMake] cmake analogue - syncProj visual studio generation tool

Hello Tarmo,
Reading this on the CMake mailing list I am first of all asking myself: Why should I go for such a certainly nice alternative if I already have CMake?
At the same time I think that _answering_ this question is probably not a subject that fits into the CMake mailing list because it is obviously for CMake issues, not ads for alternatives. So in this sense my question is rhetoric only... ;-) Providing a link to further documentation (like you are doing!) is certainly enough here - and I can see that there is the one or other function that CMake does not offer.
I am not asking _why_ you are writing this at all! If you are doing this in your free time I understand 100% the fun it is to re-invent the one or other wheel: I did that many times in the past, so I assume that I understand pretty well...
On the other hand: Just think about the fact that CMake is indeed Open Source! It means not more and not less than that nobody is constrained to the functionality that some "gods" are offering (like it is the case with the MS Visual Studio - mostly), but you would be able to add the things that you are missing and build on the many available features that others have implemented so far - and which you will have to rewrite for your project from scratch.
In other words: Standing on the shoulders of a giant gives you a phantastic view and lets you feel like you are a giant yourself! ;-)
So in short: Thanks for the free offer, but I don't need it because I have CMake!
Regards,Cornelis
Am Samstag, den 31.03.2018, 08:19 +0000 schrieb Tarmo Pikaro via CMake:
Hi !
On my own free time I've managed to create tool similar to cmake - command line tool called syncProj.
Currently syncProj is aiming also for portability, but it currently has narrower list of supported platforms - supported platforms are at this moment only Windows and Android, butonly Visual studio based.
Where cmake is using special kind of language, syncProj uses C# programming language as a base, and because of this allows full support forsyncProj C# script code syntax highlighting, intellisense and full debug support.
Documentation:https://docs.google.com/document/d/1C1YrbFUVpTBXajbtrC62aXru2om6dy5rClyknBj5zHU/edit#
Source code:https://sourceforge.net/projects/syncproj

syncProj is something that was just born on the way of making another project, and I suspect that it's far from supporting all visual studio project parameters and configurations, but it provides solid code base for future development.
So if you're familiar with C# or not familiar, but willing to learn, feel free to contact me, I can guide in syncProj code baseand teach you how to improve syncProj.
Currently syncProj supports C++, but not C#, as a platform base runs only on Windows, and limited to Windows / Android platforms.
What I have checked through Visual studio even currently start to support Linux based platforms, so if you want to or need that platform, I can guide you through how to add that support into syncProj.
Current code coverage level is 83.23% and I plan to increase that value with each future change.
------------------- Future considerations ----------------------
Currently I see syncProj as intermediate solution or a tool - I think in future syncProj could actually become built-in into Visual studio itself,as base class hierachy - something similar Microsoft guys are trying to achieve right now by integrating cmake initial support into Visual studio.
cmake scripting language dialect is more difficult to learn than C#, but of course ideal world would be if C++ project would be configured using C++ "script" syntax.
But at the moment C# allows on-fly compiling of C# code, but not C++. I think that through making C++ modules possible + allowing to compile C++ immediately - this would permit to make new variation of syncProj, which would be coded in C++ fully, but this is somethingto consider later on, after C++ modules starts working in full scale on multiple compilers.

-- Have a nice day!     Tarmo.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180331/7388dbaa/attachment-0001.html>