Closed eriknellessen closed 8 years ago
Well, you also need to compile gengetopt yourself on Windows :wink:
Do you really want to add the built files cmdline.h/c to git? That may help on Windows, when gengetopt is missing, but that will only work if you use --include-getopt
.
Also, you should add a rule to Makefile.am
for generating the source files with gengetopt and you should add a check for gengetopt itself in configure.ac.
Well, you also need to compile gengetopt yourself on Windows :wink:
Not if we add the cmdline.{c,h} to the github repository.
Do you really want to add the built files cmdline.h/c to git? That may help on Windows, when gengetopt is missing, but that will only work if you use --include-getopt.
Yes, because otherwise we can not build on windows without installing gengetopt. As I stated in #75, getopt should already be available for windows. Anyhow, we decided to use --include-getopt, so Windows has the same getopt behaviour as Linux.
Also, you should add a rule to Makefile.am for generating the source files with gengetopt and you should add a check for gengetopt itself in configure.ac.
Done in ee0b8247f600fc78b61db0f8163a27bcf9bef9a5.
OK, I'm fine with the current state of gengetopt. To be honest, I only noticed that my windows projects did not build anymore, overlooked the wingetopt part. But using gengetopt is the better solution.
Just one more thing: What do you think about including the generated ASN.1 source files? This is especially interesting, because asn1c
s behaviour for parsing INTEGERs has changed somewhere between version v0.9.28 (https://github.com/vlm/asn1c maps this to a buffer with a length) and v0.9.24 (e.g. in debian maps this to long
). Having the generated files should also work around this problem...
About the ASN1 question: I opened a new issue (#79) for that, as it is not relevant for this pull request.