Re: Hashing without relying on Qt?

2021-10-24 Thread Stephan Witt
Am 24.10.2021 um 12:23 schrieb Stephan Witt :
> 
> Am 17.10.2021 um 06:09 schrieb Richard Kimberly Heck :
>> 
>> On 10/16/21 17:15, Thibaut Cuvelier wrote:
>>> Dear list,
>>> 
>>> In my last patch (21366155), I added a dependency from InsetText to Qt to 
>>> be able to generate SHA hashes. The main goal is to have an 
>>> almost-collision-free name-generation technique, which is a great 
>>> useability enhancement, that's why I already pushed the patch. Collisions 
>>> would be awful, because two different insets would have the same file name.
>>> 
>>> I don't think Bernstein's hash (in Author.cpp) would fit the bill: it 
>>> doesn't go to great lengths to avoid collisions (it has a lot for strings: 
>>> https://softwareengineering.stackexchange.com/questions/49550/which-hashing-algorithm-is-best-for-uniqueness-and-speed).
>>> 
>>> UUID/GUID are mostly time-based or use cryptographic hash functions: they 
>>> do not really depend on the content, but mostly on time, and I need that 
>>> the file names remain constant in time (unless the LaTeX code that is 
>>> compiled gets changed).
>>> 
>>> CityHash would be enough, but that's another dependency to add to LyX 
>>> (https://github.com/google/cityhash).
>>> 
>>> The only solution I found without importing a large new dependency into LyX 
>>> was to use Qt's QCryptographicHash, just like support/FileName.cpp. I know 
>>> that LyX tries to have clear boundaries for dependencies, that's why I'm 
>>> bringing the question to the list. Is the current solution acceptable? 
>>> Maybe move some of the code to support/FileName.cpp?
>> 
>> Basically, the rule is to keep Qt dependencies that aren't in the frontend 
>> in support. Just put some wrapper function in there, and that'll be fine. 
>> Maybe in support/filetools?
> 
> Sorry for hijacking this thread…
> 
> I’m trying to build LyX-2.4 on macOS with Qt-6.2 with minimal changes to the 
> Qt-setup.  In the past I’ve „fixed“ the installed Qt instead of the build 
> system of LyX.  Now I’m trying to do the right thing and add all the 
> framework directories of Qt to the compiler command line in config/qt.m4 - 
> this works for all sources in src/frontend/qt but not e.g. for src/Compare.h 
> because there are Qt-includes and the Makefile doesn’t pass the Qt-include 
> directives to the compiler.
> 
> To add some contextual info: the header file QDate e.g. on macOS is placed in 
> the Qt framework QtCore (which is a directory with standard structure and 
> contains the shared libraries plus the header files). The QTDIR/include 
> directory doesn’t has a subdirectory QtCore or something like that. So I need 
> to add the path to the directory inside the framework bundle containing QDate 
> to the compiler flags.
> 
> My problem with the current situation is the failure to build LyX w/o 
> creating symbolic links in QTDIR/include to the different places of the 
> Qt-frameworks because of the bad Qt-dependencies of LyX sources. The 
> mentioned rule to keep Qt dependencies in src/support is not respected ATM. 
> What can I do now?

Finally I got the answer myself. There are two Qt-include variables in Makefile 
generation of configure. If I adjust both (QT_INCLUDES and QT_CORE_INCLUDES) it 
works for me.

I’ve pushed the change of qt.m4 which made it work.

BR, Stephan
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Hashing without relying on Qt?

2021-10-24 Thread Stephan Witt
Am 17.10.2021 um 06:09 schrieb Richard Kimberly Heck :
> 
> On 10/16/21 17:15, Thibaut Cuvelier wrote:
>> Dear list,
>> 
>> In my last patch (21366155), I added a dependency from InsetText to Qt to be 
>> able to generate SHA hashes. The main goal is to have an 
>> almost-collision-free name-generation technique, which is a great useability 
>> enhancement, that's why I already pushed the patch. Collisions would be 
>> awful, because two different insets would have the same file name.
>> 
>> I don't think Bernstein's hash (in Author.cpp) would fit the bill: it 
>> doesn't go to great lengths to avoid collisions (it has a lot for strings: 
>> https://softwareengineering.stackexchange.com/questions/49550/which-hashing-algorithm-is-best-for-uniqueness-and-speed).
>> 
>> UUID/GUID are mostly time-based or use cryptographic hash functions: they do 
>> not really depend on the content, but mostly on time, and I need that the 
>> file names remain constant in time (unless the LaTeX code that is compiled 
>> gets changed).
>> 
>> CityHash would be enough, but that's another dependency to add to LyX 
>> (https://github.com/google/cityhash).
>> 
>> The only solution I found without importing a large new dependency into LyX 
>> was to use Qt's QCryptographicHash, just like support/FileName.cpp. I know 
>> that LyX tries to have clear boundaries for dependencies, that's why I'm 
>> bringing the question to the list. Is the current solution acceptable? Maybe 
>> move some of the code to support/FileName.cpp?
> 
> Basically, the rule is to keep Qt dependencies that aren't in the frontend in 
> support. Just put some wrapper function in there, and that'll be fine. Maybe 
> in support/filetools?

Sorry for hijacking this thread…

I’m trying to build LyX-2.4 on macOS with Qt-6.2 with minimal changes to the 
Qt-setup.  In the past I’ve „fixed“ the installed Qt instead of the build 
system of LyX.  Now I’m trying to do the right thing and add all the framework 
directories of Qt to the compiler command line in config/qt.m4 - this works for 
all sources in src/frontend/qt but not e.g. for src/Compare.h because there are 
Qt-includes and the Makefile doesn’t pass the Qt-include directives to the 
compiler.

To add some contextual info: the header file QDate e.g. on macOS is placed in 
the Qt framework QtCore (which is a directory with standard structure and 
contains the shared libraries plus the header files). The QTDIR/include 
directory doesn’t has a subdirectory QtCore or something like that. So I need 
to add the path to the directory inside the framework bundle containing QDate 
to the compiler flags.

My problem with the current situation is the failure to build LyX w/o creating 
symbolic links in QTDIR/include to the different places of the Qt-frameworks 
because of the bad Qt-dependencies of LyX sources. The mentioned rule to keep 
Qt dependencies in src/support is not respected ATM. What can I do now?

BR, Stephan
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel