Git Lost posted a comment on ticket #5

Hi, done with commit [2bbf0e] (note it's hacky on Windows as needs -DCMAKE_BUILD_TYPE to be set the same as config).

Git Lost committed [2bbf0e] on Code

test suite: allow ctest to be run without having to install zueci or

Andre Maute posted a comment on ticket #4

Thank you Axel and gitlost for the clarifications.

Axel Waggershauser posted a comment on ticket #4

zxing-cpp compiles this without a warning on different versions of gcc and clang. I believe this is due to the fact that I had to compile it with a C compiler because clang would err out when trying to initialize a char [] with -1 entries when compiled as c++ code. I updated it anyway to keep the sources in sync for easier later updates.

Git Lost posted a comment on ticket #4

Hi Andre, committed your suggestion with [9f6171]. I think I did get this warning at one stage and then an updated g++ made it go away, but best to avoid it anyway for all versions of g++. Re this discussion I think Axel covered all the points. Will do a PR on Zing-C++ to update the copy there (or maybe Axel you'll just update it?)...

Git Lost committed [9f6171] on Code

zueci_eci_to_utf8: suppress g++ warning (ticket #4)

Axel Waggershauser posted a comment on ticket #4

is libzueci already dead? The code is very much alive but as a verbatim copy inside zxing-cpp (and basically libzint as well). The multiple issues reported with the sourceforge repo were part of the reason to include the source into zxing-cpp. Do you plan to remove WRITER support from zxing-cpp? Not anytime soon. But there might be a future where libzint is the only "backend" of zxing-cpp. how do you plan to prevent multiple versions if zint and zxing-cpp are used together? If you mean statically...

Andre Maute posted a comment on ticket #4

Hi Alex, no I haven't noticed that yet. I only read some development discussions on github for zxing-cpp from time to time. So if I might dare to ask, is libzueci already dead? I'm currently refactoring some programs for testing from one of my co-workers. Regarding the dependency of zxing-cpp 2.0.0 on libzueci, if I do see libzueci occurrences in the output while building the library, wouldn't that count indeed as a dependency. nitpicking-off I do indeed only need READER support from zxing-cpp. Do...

Axel Waggershauser posted a comment on ticket #4

Question: have you noticed that zxing-cpp version 2.0.0 is not dependent on libzueci anymore but contains a copy of the relevant files? Also there never has been a release that depended on libzueci. A lengthy discussion led to this decision. In your case I'd suggest you build zxing-cpp without WRITER support, that will effectively remove all related parts of libzueci, such that libzint and libZXing contain mutually exclusive parts of the libzueci code base.

Andre Maute posted a comment on ticket #5

sorry for the typo, should read 'Hi gitlost'.

Andre Maute created ticket #5

port a patch from Zint ticket #279

Andre Maute created ticket #4

workaround gcc warning false positive

Git Lost posted a comment on ticket #3

Removed the data files with commit [f6a630] (the generate programs now read from the net where possible) so hopefully this will go some way to addressing your concerns...

libzueci released /Download/1.0.1/README.txt

libzueci released /Download/1.0.1/libzueci-1.0.1-src.tar.gz

Git Lost committed [3302cd]

ChangeLog: 1.0.1 release date

Git Lost committed [99008b]

Update ChangeLog

Git Lost committed [f6a630]

Add ZUECI_EMBED_NO_TO_ECI and ZUECI_EMBED_NO_TO_UTF8 defines

Git Lost posted a comment on ticket #3

Hi Boyuan, thanks for the feedback. I'm no lawyer and usually wrong about copyright stuff but I notice the Debian discussion is about the code files "ConvertUTF.c" and "ConvertUTF.h" which used to reside on the Unicode Public site at "PROGRAMS/CVTUTF/". Data files aren't mentioned. The data files included here are read-only and used only to construct tables used in include files, e.g. "zueci_ksx1001.h". So I'm wondering whether the Debian discussion applies here. Do you think the generated files...

Boyuan Yang created ticket #3

Some data (tools/data/*.TXT) not considered free (violates BSD-3-Clause)

Git Lost modified ticket #2

Remove the FindZueci.cmake module

Git Lost posted a comment on ticket #2

Cool, you've been added as a committer (I think!). There might be some way to allow the creators of tickets to close them via admin but can't see it, anyway I'll close this now.

Axel Waggershauser posted a comment on ticket #2

I might follow up on your offer to add me as a committer but I don't have anything to add at the moment. I fail to see how I might close this ticket. I'm ether blind or SourceForge does not allow reporters to close tickets.

Git Lost posted a comment on ticket #2

Thanks, I've removed the FindZint.cmake install with [7f8b27] (though left the actual file in the git tree). I can add you as a committer so you can make these fixes yourself if you like... I'll do a release (1.0.1) once these issues are resolved.

Git Lost posted a comment on ticket #1

Hi, thanks, I've copied that (twice, once for shared and once for static) which hopefully is what's required with [7f8b27]

Git Lost committed [7f8b27]

- CMake: add target_include_directories() (issue #1)

Axel Waggershauser created ticket #2

Remove the FindZueci.cmake module

Axel Waggershauser created ticket #1

Export PUBLIC include directory in cmake

libzueci released /Download/1.0.0/README

libzueci released /Download/1.0.0/libzueci-1.0.0-src.tar.gz

libzueci released /Download/README

libzueci released /Download/libzueci-1.0.0-src.tar.gz

Git Lost committed [52794c]

Add ChangeLog

Git Lost committed [4e624a]

Initial version 1.0.0

Git Lost committed [b9653a]

Initial version 1.0.0