<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Aptos;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:12.0pt;
font-family:"Aptos",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Aptos",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:11.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt'>Will,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'>When strk had the bright idea to share liblwgeom with the world, we did set it to be linked.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'>This caused issues though cause we would then find new versions of postgis linking to older versions of liblwgeom and then other projects starting to use it too which meant we now had a whole set of new concerns like having to care about when we changed internal machinery in a micro version of PostGIS.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'>So we decided to close it off again. The reason it’s a separate folder is because it is a core part of most of the extensions that are part of postgis project.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'>postgis, postgis_raster, postgis_topology, postgis_sfcgal, and even sadly our commandline tools all need it and package a static copy of it for their lib/executable.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'><o:p> </o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span></b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> Will Bowers <wbowers314@gmail.com> <br><b>Sent:</b> Friday, July 19, 2024 12:49 PM<br><b>To:</b> Greg Troxel <gdt@lexort.com><br><b>Cc:</b> PostGIS Development Discussion <postgis-devel@lists.osgeo.org><br><b>Subject:</b> Re: CMake/MSVC Support<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p>Hi again all, thanks for all the additional info.<o:p></o:p></p><p>Greg, I hear you loud and clear. I am not trying to tell you to switch off your current build pipeline, I just want to see CMake supported as well. Maybe that support needs to be unofficial, and I am okay with that. I am of the opinion that PostGIS should build with all major compilers though, so I would love to help get it building on MSVC (with any build system).<o:p></o:p></p><p>Sandro, I am definitely confused here. But if the lwgeom that builds into PostGIS is not a fork, why is there an liblwgeom folder with all the source files in the postgis repo? Why build it as part of PostGIS instead of simply linking against it as you do with other libraries?<o:p></o:p></p><p>Will<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Thu, Jul 18, 2024, 5:17<span style='font-family:"Arial",sans-serif'> </span>PM Greg Troxel <<a href="mailto:gdt@lexort.com">gdt@lexort.com</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><p class=MsoNormal style='margin-bottom:12.0pt'>Will Bowers <<a href="mailto:wbowers314@gmail.com" target="_blank">wbowers314@gmail.com</a>> writes:<br><br>> Thanks for the info. Like anyone else, I have personal opinions about CMake<br>> and Meson, but those aren't terribly important right now. There are some<br><br>I have some historical info in a broad brush way. There have been a<br>lot of projects that use autoconf/automake and people show up and say<br>"cmake is better! Let's switch!". There is a "but we have to have no<br>regressions from current behavior" and the cmake people agree, and then<br>cmake support appears and it has regressions. Typically they are in<br>cross build support and in working on platforms the authors haven't<br>tested on because at least for those implementations, they lacked the<br>"feature tests only, do not ever check for a specific OS rule".<br><br>So my view, which doesn't officially count, is that to be merged any<br>cmake support must be:<br><br> as free of "ifdef FooOS" as the previous system<br><br> capable of building cross, just like autoconf<br><br> support all the --bindir/--libdir stuff that autoconf does<br><br> support proper -R and ld flags like autoconf/libtool does<br><br> support building the code and running tests, with it testing the<br> just-build code *even if there is a previous version installed*.<br><br>I think you will find it harder than it seems.<br><br>Making small fixes to improve portability is of course a separate<br>matter.<o:p></o:p></p></blockquote></div></div></div></body></html>