Swig code generation - git src vs tarball src

[Derek Atkins]

John Ralls <jralls at ceridwen.us> writes:

[snip]
>> 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 ?
>
> I wasn’t actually around for it, but I suspect that the reason was to
> avoid having SWIG as a dependency for building release tarballs. I
> think that that’s still worthy.

I was around for it.  And yes, the reason was to avoid having SWIG as a
dependency.  At the time, SWIG was not easy to build, was not shipped
with distros, and different versions of SWIG gave different outputs
which would make remote debugging of issues harder to solve.

This was also done at a time when building GnuCash was hard due to all
the dependencies, so the ability to remove one was seen as a Good
Thing(TM).  The benefit was that the code was buildable by anyone
because the generated c files were already there.  And at the time, the
generated c files worked with all versions of guile.

> I also think that it’s good that the build from a tarball based on a
> random commit fails. Since that tarball doesn’t contain any version
> information other than what’s in configure.ac, the resulting GnuCash
> will look like the last release which could produce some confusing bug
> reports.

Well, this isn't true.  You can "make dist" from any random commit and
build from the resulting tarball.  But no, you cannot just tar up a
random commit and build it.

> Regards,
> John Ralls

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available