[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] PATCH: use compressed .mst files
From: |
Greg Chicares |
Subject: |
Re: [lmi] PATCH: use compressed .mst files |
Date: |
Mon, 29 Oct 2018 10:25:12 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 |
On 2018-10-25 18:00, Vadim Zeitlin wrote:
[...]
> https://github.com/vadz/lmi/pull/100
I've done something quite similar in commit 0f81d542.
> The code changes are really simple and the only potentially questionable
> thing is the use of access() to test for the file existence, but this is
> how lmi seems to do it elsewhere, so I did it here too, even though this
> code could use wxFileName::Exists() instead or even just try to open the
> file input stream and rely on the error generated by it -- except that this
> would have required dealing with wxLog and lmi code does not do this
> anywhere else, so I didn't do it here neither.
This would have introduced a dependency on classes
wxFileInputStream
wxLZMAInputStream
wxStringOutputStream
which aren't otherwise used in lmi code. Sorry, I had thought it might
be possible to use wx's builtin liblzma more directly.
But, given that the only purpose is obfuscation, I decided to XOR the
MST files' contents with 0xFF instead of calling into any libraries.
I should have thought of that simple, robust solution up front.
> I spent more time on makefile changes than on the code because I couldn't
> figure out what would be the best or, maybe, least objectionable way of
> dealing with installing the template files. Initially I really wanted to
> rely on make for updating them, i.e. have a "%.zst: %.mst" rule, but this
> required many changes to the "install" target and, after looking at them, I
> wasn't sure if you'd like it, so I've finally implemented the current
> version which uses this "-e -o -nt" construct explicitly instead of relying
> on make. This is a bit silly but OTOH it's not that bad and like this my
> changes could be limited to pure additions, which will hopefully make them
> easier to review and integrate.
Yes, I went down the same paths before concluding that the best way to
do something that's trivial in zsh is to write a trivial zsh script.