On Wed, Feb 1, 2012 at 2:07 AM, Andreas Tille
<andreas@an3as.eu> wrote:
On Tue, Jan 31, 2012 at 06:52:28PM -0500, Bhaskar, K.S wrote:
> >I try to rephrase my suggestion.
> >
> > 1. Download a GT.M source distribution as orig.tar.gz
> > 2. Download the missing but needed autogenerated C files
> > and add them as patch set (with dpkg source format 3.0 you
> > can even have two source tarballs, but that's a detail)
> >
> >Build the package from the files exclusively without needing a running
> >GT.M.
>
> [KSB3] It could work with a slight difference.
>
> * Download the original GT.M source tarball on a system that has a GT.M
> binary. Follow the instructions in the README to build GT.M on a
> machine that has GT.M.
OK, do you know a volunteer who has GT.M installed and can easily do the
job? This would be really helpful.
I'm happy to volunteer to do this.
BTW,
My apologies for being away for the last few days,
we are drowning in preparation activities for a full
week meeting at the VA next week.
Bhaskar:
Would the GT.M installation that we have in the
VM's with VistA-FOIA work for the tests that you
are describing above ?
Also,
We just started our 7th version of the Open Source class
that we do at RPI. The students will be working on VistA
and MUMPS (using GT.M from a VM). They could also
lend us a hand in this process. Just like me, they will
need guidance from all of you.
Luis
> * Use something like diff to compare the original tarball with the new
> tarball and find the C files generated by the build process.
> * Create a new source tarball of the original files plus the new files
> and move it to a machine without GT.M (or just on the same machine,
> but don't set the environment variable that points to the existing
> GT.M). Comment out the part of the shell script that generates the
> new C source files and build GT.M.
>
> I will see what I can do about providing the additional C files
> before the release, but no promises.
Cool. That would really be a step in a promising direction.
Thanks for your support