[gdal-dev] [Proposal] Move optional raw datasets to separate directory

[thomas bonfort]

for the sake of clarity, I think I should rename the --disable-all-drivers
flag to --disable-all-optional-drivers ...

thomas

Le ven. 1 févr. 2019 à 20:58, thomas bonfort <thomas.bonfort at gmail.com> a
écrit :

> 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/6f060687/attachment.html>