Thank you jkl for your questions. Am 22.03.2020 um 00:09 schrieb James K. Lowden: > [...] > > I updated ^/branches/gnucobol-3.x and almost built it. There were two > issues I would like to report. > > 1. cJSON. > * Not packaged on Ubuntu 16.04 LTS > * built from source, per README. cmake complained verbosely about > libcurl, which it "requires", but the bulid produced seemingly good > output anyway: > > /usr/bin/cmake: /usr/local/lib/libcurl.so.4: no version > information available (required by /usr/bin/cmake) > > * I know cJSON is not required. I also doubt I'll be the last one > to encounter this particular hurdle. 30 minutes of reading cmake > documentation failed to reveal any way to print where it looks for > libraries, or to control where it looks for libraries. Feh. cJSON primarily uses CMAKE as build system (last time I've checked there is a "fall-back Makefile" you can also use which is the simplest approach [just be aware that it does not support out-of-tree-builds - something I hope to get back to some day to privide a patch for - and likely also not running the tests]). This issue (I normally don't have CMAKE available and cannot say I like it that much personally) combined with a compatible license and "you can just compile the single source and you're fine" is the reason that GnuCOBOL's configure checks for a local (to GnuCOBOL) copy if not told otherwise, and if it founds it statically link it into libcob. Checking the README it notes under optional dependencies: > The following libraries ARE required WHEN : [...] > 4) JSON runtime support is used > > BOTH runtime AND development components required. > As an alternative of an installed version you may place > cJSON.c and cJSON.h under "libcob" to include the used functions > directly in the COBOL runtime. > > cJSON >= 1.3.0 - https://github.com/DaveGamble/cJSON > > cJSON is distributed under MIT License. Do you see any option to improve this (which is the primary documentantion for the package dependency)? I've thought it to very clear and explicit. Further checking the configure messages this is also noted: If there's neither a "local" or system-installed cJSON found and you explicit asked for it via `--with-cjson` the error message says: > Headers for libcjson are required for --with-cjson, you may adjust CJSON_CFLAGS If you don't explicit ask for it you get a warning message > Headers for libcjson missing, you may adjust CJSON_CFLAGS or put cJSON sources in "libcob" So I guess the best thing to do here is to tell users to put cJSON.c+.h into libcob "somewhere" and also include it in the error message mentioned above, similar to the warning message. In any case the configure's --help should include some details about this (it doesn't), can you please suggest a patch for the script to be more detailed? > 2. Ye Olde help2man. What's the trick again? > > $ ../configure --prefix=$prefix > log && make > log > ar: `u' modifier ignored since `D' is the default (see `U') > ar: `u' modifier ignored since `D' is the default (see `U') > help2man: can't get `--help' info from ../pre-inst-env cobcrun -q > Try `--no-discard-stderr' if option outputs to stderr > [^^^^ It's unclear what this refers to --jkl] > WARNING: 'help2man' is missing on your system. > You should only need it if you modified a dependency of a man > page. You may want to install the GNU Help2man package: > <https://www.gnu.org/software/help2man/> > make[2]: *** [cobcrun.1] Error 127 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 > > This is the missing-not-missing problem: > > $ which help2man > /usr/bin/help2man > > $ help2man --version > GNU help2man 1.47.3 > ... The actual issue here is that help2man cannot start cobc as expected. I've already adjusted it (pending check-in, will be done together or near with "you may use 'pure' MPIR instead of GMP"), which should ensure that it works as long as you can make the "extras" folder (the sole reason that this may not work is a dependency on external libraries, for example gmp which were met during configure but not later on [mostly a LD_LIBRARY_PATH issue]). A "user" should normally never get an invocation of help2man, it is only done if you have newer sources than the manpages [or no manpages because you've used a checkout] - if you use a tarball (currently a nightly, next the one from alpha.gnu) then the manpages are all up to date. > Of course, the real problem with help2man isn't that it's missing. The > real problem is that it's used in the first place, ever. Your suggestion to improve the manpages by not being generated from the help but still being current (likely by include generated parts like we do for the doc/gnucobol.info + doc/GnuCOBOL.pdf) is a good one. Patches and work on the documentation are always welcomed. > One way or the other, IMHO in the coming release it should be possible > for the user to run configure successfully on a system on which all > dependencies are installed. (It would be good to get rid of the ar(1) > warnings, too.) Totally. Isn't this the case? > Recap: > > 1. What should we do about cJSON? Perhaps a helper script in > build_aux/? A script that downloads cJSON.c+h and place it into libcob to be found by configure and statically linked into libcob? Why not, please go ahead. > 2. How to make help2man work reliably? See more detailed answer above. > 3. What to do about the ar(1) messages? I'm good in ignoring those ;-) Patches that keep the result with both old binutils and current one are welcomed. > 4. Extra credit: How to eradicate the need for help2man? Provide a patch that will ensure that the man page gets not outdated automatically (which is the nice part of help2man). > > --jkl Simon
