[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

cJSON and help2man issues (was: Re: next release)

From: Simon Sobisch
Subject: cJSON and help2man issues (was: Re: next release)
Date: Sun, 22 Mar 2020 11:37:51 +0100
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0

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/ 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 -
>    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

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:
>          <>
> 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

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/ + 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]