Re: Bootstrapping GT.M
Andreas Tille <tillea@rki.de> writes:
> [I'm forewarding this to debian-devel because this seems to be the
> right list for this kind of issues.]
>
> Short intro for debian-devel: We are discussion about including GT.M,
> a free MUMPS implementation available at
> http://sourceforge.net/projects/fis-gtm
> into Debian to be able to package VistA, which is an enterprise grade
> health care information system developed by the U.S. Department of
> Veterans Affairs (VA) and deployed at nearly 1,500 facilities worldwide.
> http://sourceforge.net/projects/openvista
>
> The problem is that you need a running GT.M to build GT.M in a
> bootstrap process. Please read the mail from one of the authors below.
>
> On Mon, 11 Feb 2008, K.S. Bhaskar wrote:
>
>> [KSB] On account of the bootstrapping. You have to have a running
>> GT.M at some point, or you have to simulate a running GT.M by hand.
>> Think about bootstrapping a C compiler that is itself written in C.
>> At some point, you need to do something to compile the compiler, e.g.,
>> compile it by hand. Once you have an executable binary of the first
>> compiler, you can use it compile the next compiler, and so on. For
>> GT.M, you will need the *_ctl.c, merrors_ansi.h, and ttt.c files,
>> which are generated by GT.M itself (they are all human readable ASCII
>> files). So, what you can do is to use an existing version of GT.M to
>> create those files, read them to confirm that they look reasonable,
>> i.e., no hidden binary code, and then build the new GT.M and use the
>> new GT.M to build itself and verify that the files are the same. If
>> you can think of any other way out of the bootstrapping conundrum,
>> please do let me know.
>
> Well, if you do not know I do not have an idea either - but lets see
> whether somebody at this list comes up with some solution.
>
>>> I would like to build Debian packages to include GT.M into the Debian
>>> GNU Linux distribution. ...
>>
>> I do understand the spirit of the Debian requirement, but I wonder how
>> it is applied to gcc. You must have gcc to compile gcc.
Strictly speaking you only need a reasonable C compiler. Then again
you also need a make, shell, ld, as, ...
It is impossible to make a totaly self contained source and a lot of
wasted effort to get anywhere close. Debian has defined a set of core
packages that one can assume will always be available for building a
package (essential and build-essential packages). That include gcc so
the gcc deb relies on gcc to be available.
But even then gcc first builds a temporary compiler (xgcc) and then
compiles itself with that.
> Any idea how to solve this problem? Any volunteers to package GT.M?
>
> Kind regards
>
> Andreas.
>
> PS: There was also RFP bug #175968 filed a long time ago which was
> closed because nothing happened in this direction.
There are three things you can do:
1) Do nothing.
Once you have packages GT.M Debian will have a GT.M and you can
Build-Depend on it for future builds.
Big problem with this approach is that if the GT.M package ever breaks
(and it will) you have to bootstrap it manually on all archs to get
back on tarck again.
2) Include prebuild sources and a bootstrap target
Basically you generate the *_ctl.c, merrors_ansi.h, and ttt.c files
and put them somewhere in the source package out of the way of the
clean target. In the bootstrap target you use those prebuild sources
to build your GT.M compiler. But normaly you would just Build-Depend
on the old GT.M.
This is little more than 1 but allows you to get other people to
bootstrap GT.M for you easily if it ever breaks.
3) Include prebuild sources and bootstrap on every build
This basically means you always build twice. First you build from
prebuild sources and then you rebuild from scratch again. This has the
advantage that you don't Build-Depend on the old GT.M. A broken GT.M
upload won't break the chain.
MfG
Goswin
PS: Look at the mono packages for comparison. I think they have the
same problem.
Reply to: