[gdal-dev] [Proposal] Move optional raw datasets to separate directory
thomas bonfort
thomas.bonfort at gmail.com
Fri Feb 1 11:58:23 PST 2019
hi,
Le ven. 1 févr. 2019 à 20:39, Andrew C Aitchison <andrew at aitchison.me.uk> a
écrit :
> On Fri, 1 Feb 2019, Even Rouault wrote:
>
> > (Re-adding the list)
> >
> >>> Is the split in 2 directories for aesthetic reasons, or because it
> makes
> >>> the
> >>> conditional compiling logic easier ?
> >>
> >> The latter. I'd like to avoid modifying the cpp files themselves to add
> >> ifdefs to them.
>
> Most of the drivers I have looked at have a suitable ifdef,
> so I checked and was surprised to see that most do not
> (a rough grep suggests that 28 frmts directories have such an ifdef and 93
> do not).
>
> The pull-request talks about
> ./configure
> ... \
> disable-driver-nnnn \
> ...
>
> When using this proposal to generate minimal binaries, would
> it not be more natural to name the drivers that you wish to *enable*
> and have the configure system add whatever dependencies are required ?
> When a new driver ws added, I would like to assume that my minimal
> build would ignore it, without having to alter my build command.
>
I'm not sure you were looking at the latest version of the pull request. in
your case, you'd use
./configure --disable-all-drivers --enable-driver-nnnn
and be assured that only the nnnn driver and the mandatory ones are
included.
>
> I'm not sure about making "virt" one of the few required drivers;
> it would be hard to determine which virt files would be supported
> since a single target could use any of the other drivers.
>
that is already the case actually, although it currently only concerns
drivers that would have been added by a --with-xxxx.
I do believe it is useful to be able to use vrts along with the subset of
drivers you have chosen to enable.
Note that the target of this PR is not to generate a generic gdal build,
but rather to generate a minimal build that contains only the formats you
know will be needed, typically when building a custom docker image.
best regards,
thomas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20190201/41760a1c/attachment.html>
More information about the gdal-dev
mailing list