Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check in tools for generating generated_* files #33

Open
ghost opened this issue Jul 27, 2015 · 3 comments
Open

Check in tools for generating generated_* files #33

ghost opened this issue Jul 27, 2015 · 3 comments

Comments

@ghost
Copy link

ghost commented Jul 27, 2015

Originally reported on Google Code with ID 33

There's a lot of data files that get generated, such as cld_generated_cjk_uni_prop_80.cc
and its ilk. There have been several problems in the past with the generated files
that have necessitated post-generation fixes, e.g.:

https://code.google.com/p/cld2/source/detail?r=155
https://code.google.com/p/cld2/source/detail?r=156
https://code.google.com/p/cld2/source/detail?r=189
https://code.google.com/p/cld2/source/detail?r=192
https://code.google.com/p/cld2/source/detail?r=193

...

And now we have issue 32, which is more of the same. We don't have the templates or
whatever are used to generated these source files checked in; we should. I get that
the actual data is huge and isn't something we'd store in Git, but I'd really like
to see us put the templates/generators into the code base so that we can maintain them
alongside the code that they produce.

High priority because I feel that at this point there is likely drift between the templates
and the code they produce; we should probably get the templates checked in and iterate
on them until they produce exactly the same files that we have today, then proceed
forward with maintenance.

WDYT?

Reported by [email protected] on 2015-05-01 08:34:54

@ghost ghost self-assigned this Jul 27, 2015
@ghost
Copy link
Author

ghost commented Jul 27, 2015

Oh, right. I didn't notice (despite it having generated in the name!) that cld_generated_cjk_uni_prop_80.cc
was generated. Let me know if I can help with making/testing a patch to get issue 32
fixed.

Reported by [email protected] on 2015-05-01 18:17:39

@ghost
Copy link
Author

ghost commented Jul 27, 2015

Reported by [email protected] on 2015-06-11 15:54:02

@jmhodges
Copy link

It would be nice to get this so that folks could solve the C++0x problems with fewer weird hacks.

jmhodges added a commit to jmhodges/cld2 that referenced this issue Oct 23, 2016
Use a bunch of static_cast<uint8> to get around the c++11-narrowing
errors when building as C++0x.

This hack is necessary because the source files and generation code has
not been released.

See CLD2Owners#33 on the source file
check-in.

See CLD2Owners#47
CLD2Owners#51
CLD2Owners#26 and I'm sure there are
others for the C++0x problem.
jmhodges added a commit to jmhodges/cld2 that referenced this issue Oct 23, 2016
hack up generated files to compile as c++0x

Use a bunch of static_cast<uint8> to get around the c++11-narrowing
errors when building as C++0x.
    
This hack is necessary because the source files and generation code has
not been released.
    
See CLD2Owners#33 on the source file
check-in.
    
See CLD2Owners#47
CLD2Owners#51
CLD2Owners#26 and I'm sure there are
others for the C++0x problem.
jjhoughton pushed a commit to jjhoughton/cld2 that referenced this issue Jul 9, 2022
Use a bunch of static_cast<uint8> to get around the c++11-narrowing
errors when building as C++0x.

This hack is necessary because the source files and generation code has
not been released.

See CLD2Owners#33 on the source file
check-in.

See CLD2Owners#47
CLD2Owners#51
CLD2Owners#26 and I'm sure there are
others for the C++0x problem.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants
@jmhodges and others