[CMake] cmake analogue - syncProj visual studio generation tool

[Cornelis Bockemühl]

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, but
> only 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 for
> > syncProj C# script code syntax highlighting, intellisense and full
debug support.
> 
> Documentation:
> > https://docs.google.com/document/d/1C1YrbFUVpTBXajbtrC62aXru2om6dy5rC
lyknBj5zHU/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 base
> and 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
something
> > to 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/b4c186f9/attachment.html>