Our build system behaves differently when a build is started from a git cloned repository or from a release tarball: swig interface files are only converted into c files when building from git. The tarball assumes these should be present.
What is the original reason it was implemented this way ? Or put differently is there (still) a good reason to avoid on the fly swig code generation for a (release) tarball build ? It seems to me these diverging code paths are needlessly complicating the code. Background: I ran into this while trying to set up a nightly build system for fedora/rhel rpms. Based on the guidelines I found for Fedora's copr and tito tools I'm trying to build from a tarball that is created from the git repository (not via make dist). The build system detects it's not running from git and will fail because the swig generated files are missing. Pretending I'm building from git using BUILDING_FROM_SCM=yes will cause the build to fail as well when trying to extract version information from git... I'm not sure my experiment is achievable. But it got me thinking about this diverging code path in our source anyway. So to summarize again: What is the original reason it was implemented this way ? Or put differently is there (still) a good reason to avoid on the fly swig code generation for a (release) tarball build ? Regards, Geert _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
