Re: CMake Integration

--===============1454036639587444113==
Content-Type: multipart/alternative; boundary="0000000000004d052305956e242f"

--0000000000004d052305956e242f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Petra, I am rather sceptical about MinGW, how will it survive in the
competition with bash terminal offering full Ubuntu in Windows 10? This
week I received a letter from a colleague from Vienna university who
succeeded with installing sqltutor in the Windows bash environment.
But surely Vasileios has a point (more than a one I guess). I am planning
to write down a short summary of pros and cons.
Ale=C5=A1

On Mon, 21 Oct 2019 at 18:09, Petra Millarova <[email protected]>
wrote:

> Hi everyone!
> First of all, thank you for the contributions Vasileios! You have a valid
> point in the fact that using one build system would be better than two.
> After some research, it seems that Visual Studio actually started to
> support MinGW - at least to some extent.  (
> https://devblogs.microsoft.com/cppblog/using-mingw-and-cygwin-with-visual=
-cpp-and-open-folder/)
> I plan on trying it out later this week, I will let you know what I have
> found out, I think it might be good to use autotools only if there were n=
o
> major problems with it in VS, it would certainly make it simpler.
>
> P.
>
> On Sun, 20 Oct 2019 at 20:04, Greg Troxel <[email protected]> wrote:
>
>> I should explain one of my comments further.
>>
>> In auto*, the notion is that the configure code should test for a
>> feature, such as a library existing, or a header, or if some sample code
>> can be compiled.  None of this should ask "what OS am I on", so that
>> when it's built on a not previously contemplated OS, it just works.
>>
>> cmake may have the same notion.    But almost always when I deal with
>> packages that have cmake build systems and that do not actually build (o=
n
>> the system I am building them on), I see a lot of conditionals about OS
>> type.
>>
>> So I'd say that if the cmake code has "if this is a mac, do X", or
>> similar, that's a bug and should be removed, in favor of a feature test.
>>
>> Of course, another view is that the cmake build should be only for
>> windows, in which case
>>
>> if this os is not windows
>>   throw an error
>>
>> is a good approach.
>>
>>
>>
>>

--0000000000004d052305956e242f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Petra, I am rather sceptical about MinGW, how will it=
 survive in the competition with bash terminal offering full Ubuntu in Wind=
ows 10? This week I received a letter from a colleague from Vienna universi=
ty who succeeded with installing sqltutor in the Windows bash environment.<=
/div><div>But surely Vasileios has a point (more than a one I guess). I am =
planning to write down a short summary of pros and cons.</div><div>Ale=C5=
=A1<br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D=
"gmail_attr">On Mon, 21 Oct 2019 at 18:09, Petra Millarova &lt;<a href=3D"m=
ailto:[email protected]">[email protected]</a>&gt; wrote:<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi=
 everyone!=C2=A0<br>First of all, thank you for the contributions=C2=A0Vasi=
leios! You have a valid point in the fact that using one build system would=
 be better than two. After some research, it seems that Visual Studio actua=
lly started to support MinGW - at least to some extent.=C2=A0 (<a href=3D"h=
ttps://devblogs.microsoft.com/cppblog/using-mingw-and-cygwin-with-visual-cp=
p-and-open-folder/" target=3D"_blank">https://devblogs.microsoft.com/cppblo=
g/using-mingw-and-cygwin-with-visual-cpp-and-open-folder/</a>) I plan on tr=
ying it out later this week, I will let you know what I have found out, I t=
hink it might be good to use autotools only if there were no major problems=
 with it in VS, it would certainly make it simpler.=C2=A0<br><br>P.</div><b=
r><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, =
20 Oct 2019 at 20:04, Greg Troxel &lt;<a href=3D"mailto:[email protected]" tar=
get=3D"_blank">[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex">I should explain one of my comments further.<b=
r>
<br>
In auto*, the notion is that the configure code should test for a<br>
feature, such as a library existing, or a header, or if some sample code<br=
>
can be compiled.=C2=A0 None of this should ask &quot;what OS am I on&quot;,=
 so that<br>
when it&#39;s built on a not previously contemplated OS, it just works.<br>
<br>
cmake may have the same notion.=C2=A0 =C2=A0 But almost always when I deal =
with<br>
packages that have cmake build systems and that do not actually build (on<b=
r>
the system I am building them on), I see a lot of conditionals about OS<br>
type.<br>
<br>
So I&#39;d say that if the cmake code has &quot;if this is a mac, do X&quot=
;, or<br>
similar, that&#39;s a bug and should be removed, in favor of a feature test=
.<br>
<br>
Of course, another view is that the cmake build should be only for<br>
windows, in which case<br>
<br>
if this os is not windows<br>
=C2=A0 throw an error<br>
<br>
is a good approach.<br>
<br>
<br>
<br>
</blockquote></div>
</blockquote></div>

--0000000000004d052305956e242f--


--===============1454036639587444113==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KQnVnLWdhbWEg
bWFpbGluZyBsaXN0CkJ1Zy1nYW1hQGdudS5vcmcKaHR0cHM6Ly9saXN0cy5nbnUub3JnL21haWxt
YW4vbGlzdGluZm8vYnVnLWdhbWEK

--===============1454036639587444113==--