Do we want to put generated files (bison/flex/gettext/pdf) into svn?

GnuCOBOL
2014-08-13
2014-10-04
  • Simon Sobisch
    Simon Sobisch
    2014-08-13

    I'm merging the old cvs history from Keisuke and Roger with the current svn repo "code" (that was started with the full contents of the 1.1pre-rel-tarball).
    The first thing that is quite different is the handling of generated files:

    Files generated by bison/flex/gettext/makeinfo weren't included in cvs. Files generated by automake/autoconf are included

    Pro: lesser changes to commit, mostly sources only in version management. No conflicts because of different bison/flex versions. But still ./configure && make works.
    Contra: everyone that wants to compile from version management needs both bison and flex in applicable versions (gettext kicks in automatically if it's available, if not you won't have translations anyway).

    For all "normal" users you have to post a "nightly-build-tarball" (this can be both pro [as it is available] and con [as it has to be generated and uploaded]).

    I currently tend to do it "the old way" and kicking out the generated files during the merge of "old" and "new" version management.

    Please share your opinions about this issue.

    Simon

     
    Last edit: Simon Sobisch 2014-08-13
    • Brian Tiffin
      Brian Tiffin
      2014-08-14

      I've mentioned/admitted this in the past, but Autotools Fu is strange Fu.

      We need to get our heads around clean use of maintainer-mode.

      http://www.gnu.org/software/automake/manual/html_node/maintainer_002dmode.html

      I get lost soon after wading in, but we frequently fail make distcheck now, especially with out-of-tree builds.

      Ummm...? :-)

      Cheers,
      Brian

       
  • Philipp Böhme
    Philipp Böhme
    2014-08-14

    In my opinion configuring and building should be as easy as possible. Therefore I'd like to see the build-ready parser.c, scanner.c etc. in the repository. Anyone who likes to create them manually is still free to do so.

    Second point is the "build-windows" directory. For Windows we need to ship those files anyway or we expect everybody to have a (working) mingw distribution with bison/flex to create them.
    For windows builds (with Visual Studio) we also need some libraries (mpir, pdcurses etc.) which should be available in some way.

    I think we should offer at least a kind of side package for this stuff, if we kick it out of the main repo.

    Greetz, Philipp

     
  • Simon Sobisch
    Simon Sobisch
    2014-08-14

    We only talk about the source repository.
    On (pre-)release there will be the already known .tar.gz including the generated parser.c, ... and new a .source.zip for Windows including the generated parser.c and build_windows from trunk. These can be used for compilation. We may add a nightly with generated files from time to time for both .tar.gz and .source.zip.
    There will be "ready-to-use-binaries, too".
    Concerning bison/flex for windows there is either the cygwin/Mingw possibility or single tools with installer available (configurable as external build tools in VisualStudio if one likes to use them). It's a good idea to add the necessary external libs + header files + dlls in a win-libs download (better ideas for the name are welcome).

    TODO (for whomever ;-) including detailed information about this in build_windows/README.

    Simon

     
  • Howard Chu
    Howard Chu
    2014-08-16

    My preference is to include bison/flex output in a source repo because they tend to be configure/platform independent and thus there's no reason for everyone else to regenerate them. Oftentimes I have to build software on older systems where these tools aren't installed and aren't convenient to install, and I find myself generating on some other box instead and scp'ing the output over. Wasted effort, IMO.