FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 02-12-2008, 05:30 AM
Andreas Tille
 
Default Bootstrapping GT.M

[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.


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.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-12-2008, 07:57 AM
Goswin von Brederlow
 
Default 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.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-12-2008, 09:46 AM
Petter Reinholdtsen
 
Default Bootstrapping GT.M

[Andreas Tille]
> Any idea how to solve this problem? Any volunteers to package GT.M?

What about providing the generated files in the initial upload? The
files can them be used to bootstrap the system on the autobuilders.
The initial upload can't build-depend on itself, but when it is built,
the next upload can build-depend on the previous version of itself.

Gcc compiles itself several times during bootstrapping, first a
minimal version that can use almost any C compiler, then itself with
the minimal version, and finally itself with the full version of
itself. Perhaps something similar should be done with GT.M? I
realize that the situation is different as there is no M compiler
included by default in Debian.

Happy hacking,
--
Petter Reinholdtsen


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-16-2008, 06:37 AM
Andreas Tille
 
Default Bootstrapping GT.M

Hi,

I'm just forewarding the answer of upstream about the possibilities
for the bootstrapping process ...

Any comments?

Kind regards

Andreas.

---------- Forwarded message ----------
Date: Fri, 15 Feb 2008 17:38:59 -0500
From: K.S. Bhaskar <ks.bhaskar@fnis.com>
To: Andreas Tille <tillea@rki.de>
Subject: Re: Bootstrapping GT.M (fwd)

Andreas --

Sorry for the delayed reply, but I was caught up with some urgent work.

The way we bootstrap GT.M is that we use the previous release of GT.M to build
it. If you like, we are happy to provide you with the files from our build of
GT.M V5.3-001 (the current version), which will let you build it for yourself.
Alternatively, you can use the released binaries to build your own fresh
binaries from the released sources. But, just as there must be a C compiler to
build gcc, GT.M needs a MUMPS implementation - GT.M itself since there is no
alternative - to build GT.M. I don't see an easy way out of this conundrum.
There is of course no technical obstacle to replacing the bootstrap with awk or
perl programs, but that would be more work for us with no clear benefit.


In any case, it looks like there is precedent in the Debian world for
bootstrapping by requiring an existing binary for building a new binary.


Regards
-- Bhaskar

On 02/12/2008 09:24 AM, Andreas Tille wrote:

Just forewarding you one answer from the list where you was not
included in CC.

Kind regards

Andreas.



[Andreas Tille]
> Any idea how to solve this problem? Any volunteers to package GT.M?

What about providing the generated files in the initial upload? The
files can them be used to bootstrap the system on the autobuilders.
The initial upload can't build-depend on itself, but when it is built,
the next upload can build-depend on the previous version of itself.

Gcc compiles itself several times during bootstrapping, first a
minimal version that can use almost any C compiler, then itself with
the minimal version, and finally itself with the full version of
itself. Perhaps something similar should be done with GT.M? I
realize that the situation is different as there is no M compiler
included by default in Debian.

Happy hacking,
--
Petter Reinholdtsen



--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-17-2008, 08:01 AM
Petter Reinholdtsen
 
Default Bootstrapping GT.M

[Andreas Tille]
> Hi,
>
> I'm just forewarding the answer of upstream about the possibilities
> for the bootstrapping process ...
>
> Any comments?

I would suggest you ask upstream to include a set of generated files
in the upstream tarball, to make it possible to bootstrap the tarball
using a C compiler instead of requiring a M compiler. It could then
as the normal build first build the M compiler using a C compiler and
the bootstrap files, next generate the same files using its freshly
built M compiler, and last build these files once or twice if it want
to check that the generated files were correct. It would be fairly
close to how gcc does it.

It would be a lot easier to bootstrap the M compiler if it included
code to start with a C compiler, as a C compiler is available on all
distributions and architectures, while an M compiler is not.

Happy hacking,
--
Petter Reinholdtsen


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-17-2008, 11:51 AM
Andreas Tille
 
Default Bootstrapping GT.M

On Sun, 17 Feb 2008, Petter Reinholdtsen wrote:


I would suggest you ask upstream to include a set of generated files
in the upstream tarball, to make it possible to bootstrap the tarball
using a C compiler instead of requiring a M compiler. It could then
as the normal build first build the M compiler using a C compiler and
the bootstrap files, next generate the same files using its freshly
built M compiler, and last build these files once or twice if it want
to check that the generated files were correct. It would be fairly
close to how gcc does it.

It would be a lot easier to bootstrap the M compiler if it included
code to start with a C compiler, as a C compiler is available on all
distributions and architectures, while an M compiler is not.


Well, if I understood K.S. Bhaskar's last mail right this might be
possible in theory but would require a certain amount of extra work
for them which they are not willing to do because it has no profit
for their work.

Kind regards

Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-17-2008, 12:08 PM
Petter Reinholdtsen
 
Default Bootstrapping GT.M

[Andreas Tille]
> Well, if I understood K.S. Bhaskar's last mail right this might be
> possible in theory but would require a certain amount of extra work
> for them which they are not willing to do because it has no profit
> for their work.

I only read that they were against spending time to write code to
generate the M compiler source without a M compiler, not that they
were against providing pregenerated files in the source tarball.

And if they are against doing extra work, someone else can do the work
and provide patches to them. I suspect this extra work need to be
done anyway to get the package built on the Debian autobuilders, so it
is more a question of who do the work and how is it maintained in the
future, than it is a question of what to do.

Happy hacking,
--
Petter Reinholdtsen


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-17-2008, 11:22 PM
Mirco Bauer
 
Default Bootstrapping GT.M

On Tue, 2008-02-12 at 09:57 +0100, Goswin von Brederlow wrote:
> 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.

We had that problem [0] with older mono versions, but luckily upstream
rewrote their build-system later. The mono source package had a
build-dep on mcs, and mcs on mono as mcs is contains the source of
the C# compiler and C# libraries and mono the runtime.

Today it uses 2 stages to build the runtime.
Stage 1: it builds the C runtime part and then with that the C# compiler
using a pre-compiled C# compiler and corlib that are part of the tarball
(that works because the generated CIL bytecode is arch-independent).
Stage 2: it uses the built C# compiler to build the rest of the C#
libraries.

So we had the 1) option and use today the 3) option.

[0] http://pkg-mono.alioth.debian.org/BUILD_MONO_FROM_SCRATCH_HOWTO

--
Regards,

Mirco 'meebey' Bauer

PGP-Key ID: 0xEEF946C8

FOSS Developer meebey@meebey.net http://www.meebey.net/
PEAR Developer meebey@php.net http://pear.php.net/
Debian Developer meebey@debian.org http://www.debian.org/
 

Thread Tools




All times are GMT. The time now is 05:18 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org