Re: Re-organizing source tree regarding drivers?

--===============5446184879621034854==
Content-Type: multipart/alternative; boundary="000000000000caacba06518d9556"

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

A reorg makes a lot of sense to me. Thanks for proposing it.

I would lean towards just having a `drivers/` directory.

A reorg will cause me a serious amount of pain because I work in the
google3 mono repo:

1) I use copybara to bring GDAL into google3 and build with a custom
bazel setup.
2) There are > 400 files spread across many teams that will need headers
changed.

But, that's my problem and shouldn't influence the decision.

On Wed, May 6, 2026 at 5:28=E2=80=AFPM Even Rouault via gdal-dev <
[email protected]> wrote:

> Hi,
>
> with a number of drivers being raster+vector our current source tree
> organization is a bit messy.
>
> For example, we have:
>
> - ogr/ogrsf_frmts/gpkg: the GeoPackage driver started vector-only and
> then raster was added
>
> - frmts/mbtiles: the MBTiles driver started raster-only and then vector
> was added
>
> - ogr/ogrsf_frmts/pmtiles: you can guess what I will write here
>
> - frmts/mem
>
> I'm hesitating between:
>
> - putting all drivers below a drivers/  directory
>
> - or having drivers/raster/ , drivers/vector/ and drivers/mixed/
>
> This later organization avoids a bit the issue of a monolithic drivers/
> with 250+ subdirectories (who knows if Windows might not limit to 256
> :-)),  but it may involve moving code around when something that was
> raster or vector only later gains the other capability.
>
> We should likely migrate OGR_ENABLE_DRIVER_XXXX CMake variables to using
> the GDAL_ prefix.
>
> And C entry points for plugins would be all GDALRegisterXXXX() and
> shared libary names all gdal_XXXXX.dll/so
>
> While we are it:
>
> - gcore/ would be split between core/generic (driver and dataset
> classes) and core/raster.
>
> - gcore/multidim/ --> core/multidim/
>
> - ogr/ and ogr/ogrsf_frmts/generic would become core/vector/  , possibly
> with a core/vector/geometry for core geometry classes, and core/crs/ for
> OSR related classes
>
> Thoughts? (I'm wondering how such a plan could be executed without
> freezing all pull request activity in the meantime to limit conflicts,
> although git might perhaps be smart enough to detect files moving around)
>
> Even
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
> Highly recommend OxiGDAL if you want to live in the 21th century and cure
> Bixonimania
>
> _______________________________________________
> gdal-dev mailing list
> [email protected]
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>

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

<div dir=3D"ltr">A reorg makes a lot of sense to=C2=A0me. Thanks for propos=
ing it.<div><br></div><div>I would lean towards just having a `drivers/` di=
rectory.</div><div><br></div><div>A reorg will cause me a serious amount of=
 pain because I work in the google3 mono repo:</div><div><br></div><div>1) =
I use copybara=C2=A0to bring GDAL into google3 and build with a custom baze=
l=C2=A0setup.</div><div>2) There are &gt; 400 files spread across many team=
s that will need headers changed.</div><div><br></div><div>But, that&#39;s =
my problem and shouldn&#39;t influence the decision.</div></div><br><div cl=
ass=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_a=
ttr">On Wed, May 6, 2026 at 5:28=E2=80=AFPM Even Rouault via gdal-dev &lt;<=
a href=3D"mailto:[email protected]">[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(204,204,204);padding-left:1ex">Hi,<br>
<br>
with a number of drivers being raster+vector our current source tree <br>
organization is a bit messy.<br>
<br>
For example, we have:<br>
<br>
- ogr/ogrsf_frmts/gpkg: the GeoPackage driver started vector-only and <br>
then raster was added<br>
<br>
- frmts/mbtiles: the MBTiles driver started raster-only and then vector <br=
>
was added<br>
<br>
-=C2=A0ogr/ogrsf_frmts/pmtiles: you can guess what I will write here<br>
<br>
- frmts/mem<br>
<br>
I&#39;m hesitating between:<br>
<br>
- putting all drivers below a drivers/=C2=A0 directory<br>
<br>
- or having drivers/raster/ , drivers/vector/ and drivers/mixed/<br>
<br>
This later organization avoids a bit the issue of a monolithic drivers/ <br=
>
with 250+ subdirectories (who knows if Windows might not limit to 256 <br>
:-)),=C2=A0 but it may involve moving code around when something that was <=
br>
raster or vector only later gains the other capability.<br>
<br>
We should likely migrate OGR_ENABLE_DRIVER_XXXX CMake variables to using <b=
r>
the GDAL_ prefix.<br>
<br>
And C entry points for plugins would be all GDALRegisterXXXX() and <br>
shared libary names all gdal_XXXXX.dll/so<br>
<br>
While we are it:<br>
<br>
- gcore/ would be split between core/generic (driver and dataset <br>
classes) and core/raster.<br>
<br>
- gcore/multidim/ --&gt; core/multidim/<br>
<br>
- ogr/ and ogr/ogrsf_frmts/generic would become core/vector/=C2=A0 , possib=
ly <br>
with a core/vector/geometry for core geometry classes, and core/crs/ for <b=
r>
OSR related classes<br>
<br>
Thoughts? (I&#39;m wondering how such a plan could be executed without <br>
freezing all pull request activity in the meantime to limit conflicts, <br>
although git might perhaps be smart enough to detect files moving around)<b=
r>
<br>
Even<br>
<br>
-- <br>
<a href=3D"http://www.spatialys.com" rel=3D"noreferrer" target=3D"_blank">h=
ttp://www.spatialys.com</a><br>
My software is free, but my time generally not.<br>
Highly recommend OxiGDAL if you want to live in the 21th century and cure B=
ixonimania<br>
<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">gdal-dev@list=
s.osgeo.org</a><br>
<a href=3D"https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel=3D"norefe=
rrer" target=3D"_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</=
a><br>
</blockquote></div>

--000000000000caacba06518d9556--

--===============5446184879621034854==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev

--===============5446184879621034854==--