[cmake-developers] QtAutogen 3.6.0 directory nesting overflow patch

[Sebastian Holtermann]

Am 09.08.2016 um 16:11 schrieb Brad King:
> On 08/08/2016 04:19 PM, Sebastian Holtermann wrote:
>> It is back to what it was in 3.5 for the all-qrc-names-unique case.
>> So yes, existing projects get the same symbol name they used to get.
>
> Good, thanks.
>
>> New projects that now can use non unique file names
>> may get a symbol name based on the checksum extended file name
>> - but that one is also length limited and should be safe.
>
> Is this checksum user-facing in that they may need to reference such
> a symbol in their own code by this name?  This would restrict us from
> ever changing the hash algorithm in the future.

Well, it is user-facing.
Though for one-binary applications the user never needs
to know the the actual symbol name. Only when building libraries.

It is said n "Using Resources in a Library" in
http://doc.qt.io/qt-5/resources.html
--
Note: The use of Q_INIT_RESOURCE() and Q_CLEANUP_RESOURCE() is not 
necessary when the resource is built as part of the application.
--

In the non-unique-qrc-name case the checksum is hard to reproduce for a 
user. In this case I'd say CMake does not make any guaratees for
  - the actual symbol name
  - the symbol name to not change in the future
It only guarantees the symbol to be unique within the project.

If the user really needs a guranteed symbol name, e.g. for a library, 
he/she has to ensure that the BASENAME.qrc file name is unique within 
the project. In CMake 3.5 this was a requirement anyway.


>> But I found another issue.
>> The checksum string generator may generate a '-' in the file name.
>> This is allowed for file names but not for symbol names.
>> I have attached a small patch to fix this.
>
> Thanks, I squashed that in.
>
> Why does cmFilePathUuid::GetChecksumString go through so many steps
> of transformation?  Why not just take the original hex-valued hash
> and use it directly (possibly truncated)?

Base64 uses 64 different characters. Hex values only 16.
Using Base64 the 14 character checksum string allows 64**14
different combinations versus 16**14 combinations when using hex.
Therefore a checksum collision is less likely when using Base64.

I'm not tied to Base64 but I think it provies the best uniqueness
with respect to the file-length and allowed-characters limitations.

-Sebastian