bison dependency is missing

[Ninjapouet]

./configure tells all is ok but make gives:

make[2]: Entering directory '/home/julius/ocp/gnucobol/cobc'
/bin/bash ../build_aux/ylwrap ppparse.y y.tab.c ppparse.c y.tab.h `echo ppparse.c | sed -e s/cc$/hh/ -e s/cpp$/hpp/ -e s/cxx$/hxx/ -e s/c++$/h++/ -e s/c$/h/` y.output ppparse.output -- yacc
../build_aux/ylwrap: line 175: yacc: command not found
make[2]: *** [Makefile:653: ppparse.c] Error 127

[GitMensch]

This dependency is seen in HACKING - you only need it if you build from version control, commonly you'll build from a release tarball for example from your nearest GNU ftp mirror or use a CI build (just choose one, then get the "gnucobol-ci source distribution").

Note that we use GitHub primarily as mirror, see https://www.gnu.org/software/gnucobol/ for official information and discussion boards/mailing lists.

[Ninjapouet]

Why this distinction between version controlled sources and release tarballs/ci builds ?

[GitMensch]

A release tarball only needs a minimal set of developer tools (autoconf/automake/bison/flex/help2man/gettext/texinfo/texlive -> all not needed, if you have them installed then the version doesn't matter; especially the last one as distro-install can weight in hundreds of MB; and on some systems you don't even have all those tools in the minimal version if you don't build them and their dependencies from source in the first place).

A release tarball is also only created when all internal tests pass, while a given version control snapshot may not be in that state.

[Ninjapouet]

I don't understand your argument : what's the connection with telling configure to check for required dev tools in versioned control sources (and distinguish between "HACKING" and release modes if you care about it) ?

[GitMensch]

I don't understand the question, probably because I'm not a native English speaker. Please rephrase.

[Ninjapouet]

Why your release considerations are preventing proper usage of configure ? When I run gcc's configure, make is supposed to work after that, whatever i'm using versionned sources or release tarballs.

[GitMensch]

At least for bison and flex: GCC seems to include both the source and the generated files in git. The only practical way to do that is that all developers have the same setup or manually diff into the generated files (the generated bison headers (or at least the one I saw with the last commit in 2020) say by GNU bison 1.35! - and added a bison3 compatibility...).

We decided against that because the developers of GnuCOBOL faced a lot of conflicts and non-changes and huge unnecessary diffs as soon as someone compiles. All generated files were removed from version control years ago.

The version control system is primarily for developers, while (nightly) release tarballs are for users. A lot of users "are" developers, they may install the additional tools mentioned in HACKING.

[Ninjapouet]

I think there is a misleading here. The issue isn't about generated files but dev tools we need according to a given production mode. Whatever is the reason to distinguish dependencies in dev mode and release mode, I still don't understand why you can't just tell autoconf tools that there are two dev tools set dependencies and to select the correct one according to the production mode.

[GitMensch]

Feel free to provide a patch that adds --check-maintainer-tools or similar. The important thing is that those should not be checked at all for a normal "configure".

The make part is already done: those files are only (re)built if they aren't up to date.