Re: Ada build now requires gnatmake?

Re: Ada build now requires gnatmake?

[Richard Kenner]

    I just did an update and tried a bootstrap, and it seems that gnatmake
    is used to build the Ada compiler, specifically to build treeprs.ads,
    einfo.h, sinfo.h, and nmake.adb.  I thought bootstrapping was only
    supposed to require the compiler and gnatbind.

Those files are in the tree, but you may have to do a "touch" if they are older
than what they depend on.

Re: Ada build now requires gnatmake?

[Joe Buck]

>     I just did an update and tried a bootstrap, and it seems that gnatmake
>     is used to build the Ada compiler, specifically to build treeprs.ads,
>     einfo.h, sinfo.h, and nmake.adb.  I thought bootstrapping was only
>     supposed to require the compiler and gnatbind.

Kenner writes:

> Those files are in the tree, but you may have to do a "touch" if they are older
> than what they depend on.

Perhaps contrib/gcc_update should be updated to take care of this?  It
already does the same for other such files where the derived file is
in the tree.

Re: Ada build now requires gnatmake?

[guerby]

> Perhaps contrib/gcc_update should be updated to take care of this?  It
> already does the same for other such files where the derived file is
> in the tree.

Already in:

2001-11-07  Laurent Guerby <guerby@acm.org>

	* gcc_update (files_and_dependencies): Add Ada dependencies.

-- 
Laurent Guerby <guerby@acm.org>

Re: Ada build now requires gnatmake?

[Geert Bosch]

On Tuesday, December 4, 2001, at 05:51 , <guerby@acm.org> wrote:
> Anyway, the xtools are useful only on reasonable build machines where
> your do expect to do regular development, so I don't think the gnat1
> restriction apply if they still exist. The generated files are target
> independant so you're free to build them on any reasonable machine and
> transfer them, that's why no one really bothered with Makefile rules
> up to now, and when they were put in, a preexisting gnatmake was
> deemed an appropriate requirement. We can lower the requirement to
> just gnat1 and gnatbind but it doesn't have much value added.

Yes, I agree with this. I appreciate Zack's offer to rewrite the 
utilities
in C, but I don't think it has much added value. Anybody doing 
development
on GNAT has by definition access to the full compiler with tools 
(even if only
after the first bootstrap).

Right now, my highest priority is to get up to speed with 
integrating ACT
changes back into the tree.

   -Geert

Re: Ada build now requires gnatmake?

[guerby]

I don't know if the old rules about not depending on the secondary
stack still apply, from the current Makefile.in I'd infer that only
gnat1 does not depend on s-secsta, gnatbind and all other tools do.

Anyway, the xtools are useful only on reasonable build machines where
your do expect to do regular development, so I don't think the gnat1
restriction apply if they still exist. The generated files are target
independant so you're free to build them on any reasonable machine and
transfer them, that's why no one really bothered with Makefile rules
up to now, and when they were put in, a preexisting gnatmake was
deemed an appropriate requirement. We can lower the requirement to
just gnat1 and gnatbind but it doesn't have much value added.

Note that the existing Makefile rules do have the value of getting an
error if you do not have up to date generated files and no gnatmake,
which is a much better situation than silently building a crashing
compiler. I guess Corey is thankful to this, the problem was caught in
a few minutes instead of painful hours of debugging :).

-- 
Laurent Guerby <guerby@acm.org>

Re: Ada build now requires gnatmake?

[Florian Weimer]

<guerby@acm.org> writes:

> I reread the discussions, and no message carries a patch that applies
> cleanly any longer. While I'm at it I'll submit a patch that merges
> some common code for those Ada file generating tools (xtreeprs,
> xsinfo, xeinfo and xnmake - 1665 SLOC total), provides a wrapper tool
> and a Makefile target that does not use gnatmake to get things done
> and is parallel-safe.

If you want to eliminate the use of gnatmake in order to enable
building with a minimal GNAT version, I'm not sure if you will achieve
this goal with your approach.  IIRC, some of the tools use the
GNAT.Spitbol packages, which in turn depend on Ada.Strings.Unbounded,
which is not available with a minimal GNAT installation (at least
there's an undocumented coding requirement in this direction).

Re: Ada build now requires gnatmake?

[dewar]

xsnames is a useful utility if a name is to be added to the snames.ads
package (it adjusts the numbering, and creates a matching snames.adb).

Re: Ada build now requires gnatmake?

[guerby]

> Please send a reminder with a link to the patch you sent

I reread the discussions, and no message carries a patch that applies
cleanly any longer. While I'm at it I'll submit a patch that merges
some common code for those Ada file generating tools (xtreeprs,
xsinfo, xeinfo and xnmake - 1665 SLOC total), provides a wrapper tool
and a Makefile target that does not use gnatmake to get things done
and is parallel-safe.

BTW, I just noticed xsnames.adb, does it still serve a useful purpose?

-- 
Laurent Guerby <guerby@acm.org>

Re: Ada build now requires gnatmake?

[Geert Bosch]

On Tuesday, December 4, 2001, at 03:14 , <guerby@acm.org> wrote:
> I haven't bothered to offer a patch since a previous patch on this
> area on the Makefile hasn't been reviewed in a while (it was to make
> the tmp-dir a common target so that parallel build works, can't find
> the URL right now - I don't remember who submitted it).
>
> If people are ready to review patches in the area in a reasonable time
> frame I can submit one fixing the issue on short notice.

Please send a reminder with a link to the patch you sent. I try to
answer queries and approve patches within a week and mostly right
away, but it may happen that something falls through the cracks.
This is especially the case if a proposed patch generates a lot
of discussion.

   -Geert

Re: Ada build now requires gnatmake?

[guerby]

> My offer to rewrite the generator programs in C stands.

No need to get there to remove the dependancy on gnatmake, you just
need to write a few Makefile rules to get rid of it and do the thing
on the host with only compiler and gnatbind available.

I haven't bothered to offer a patch since a previous patch on this
area on the Makefile hasn't been reviewed in a while (it was to make
the tmp-dir a common target so that parallel build works, can't find
the URL right now - I don't remember who submitted it).

If people are ready to review patches in the area in a reasonable time
frame I can submit one fixing the issue on short notice.

-- 
Laurent Guerby <guerby@acm.org>

Re: Ada build now requires gnatmake?

[Geert Bosch]

On Tue, 4 Dec 2001, Zack Weinberg wrote:
> I thought the generated files had been taken out of CVS?

No, IIRC the opinion was that these files should stay checked in,
at least for now.

On Tuesday, December 4, 2001, at 02:39 , Joseph S. Myers wrote:
>
> I thought that the generated files were now mentioned in
> contrib/gcc_update, so if you update with that or use 
> contrib/gcc_update
> --touch after updating you shouldn't see the problem.

I once submitted a patch for that, but never got feedback and I thought
it might be OBE. I'll check whether sources are automatically updated
and if not propose a patch for that. This will have to wait until next
week though, so if anybody wants to have a look at it before, that would
be great.

> At some point after 3.1 we might then decide that gnatmake is a 
> tool that
> people building Ada from CVS (and people building release 
> distributions)
> need to have installed, remove the files from CVS and gcc_update, make
> "make maintainer-clean" remove them, and arrange for the release 
> script to
> put them in the source directory if the build puts them in the build
> directory.

This seems like a good approach to me.

   -Geert

Re: Ada build now requires gnatmake?

[Joseph S. Myers]

On Tue, 4 Dec 2001 guerby@acm.org wrote:

> > I thought that the generated files were now mentioned in
> > contrib/gcc_update, so if you update with that or use contrib/gcc_update
> > --touch after updating you shouldn't see the problem.
> 
> You'll get not-in-synch generated files, so you'll probably either
> won't be able to build or build a non-functional compiler. It is my
> understanding that gcc_update is intended just to make sure timestamp
> are rights before making a release tarball, but it can't make sure
> sources are right :).

gcc_update --touch works on the following basis:

* People checking in source files will check in files generated from them 
if there are any changes to the generated file (many changes to the source 
file may not cause such changes, in some cases), but CVS updates or 
applying patches might have left the timestamps in the wrong order even 
though the files are in fact up to date.

* When a generated file is removed from CVS, it is also removed from
gcc_update (otherwise it does indeed get touched wrongly and stay out of
date).

If, for example, "autoconf" on your PATH is 2.5x rather than 2.13, you
need to use gcc_update or you'll get breakage from bogus attempts to
regenerate configure scripts with a too-recent version.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Ada build now requires gnatmake?

[guerby]

> I thought that the generated files were now mentioned in
> contrib/gcc_update, so if you update with that or use contrib/gcc_update
> --touch after updating you shouldn't see the problem.

You'll get not-in-synch generated files, so you'll probably either
won't be able to build or build a non-functional compiler. It is my
understanding that gcc_update is intended just to make sure timestamp
are rights before making a release tarball, but it can't make sure
sources are right :).

-- 
Laurent Guerby <guerby@acm.org>

Re: Ada build now requires gnatmake?

[Joseph S. Myers]

On Tue, 4 Dec 2001, Zack Weinberg wrote:

> > Yes, you're right. I have checked in a patch to einfo.ads and forgot
> > to update the dependent sources, and sinced I have gnatmake on my
> > system this didn't show up during bootstrap. I'll fix this and think
> > about ways to ensure this doesn't happen again.
> 
> I thought the generated files had been taken out of CVS?

I thought that the generated files were now mentioned in
contrib/gcc_update, so if you update with that or use contrib/gcc_update
--touch after updating you shouldn't see the problem.

At some point after 3.1 we might then decide that gnatmake is a tool that
people building Ada from CVS (and people building release distributions)
need to have installed, remove the files from CVS and gcc_update, make
"make maintainer-clean" remove them, and arrange for the release script to
put them in the source directory if the build puts them in the build
directory.

It may not be documented, but I claim that the rules should be:

* Generated files are included in CVS iff they are not removed in
maintainer-clean.

* Any generated files needed to run configure and start building the
distribution are included in CVS (per the GNU Coding Standards on
maintainer-clean).  Other generated files are only included in CVS if they
are needed for build and we feel that the necessary tools to regenerate
them are sufficiently obscure or non-portable, or the requirements for a
specific version of them too restrictive, that people using CVS should not 
be expected to have them installed.

* The requirements for people building from snapshots are the same as
those for building from CVS.

* Where possible, architecture-independent generated files should be
included in release tarballs rather than requiring additional tools to be
installed by people building releases.  This includes Info files,
generated man pages, Bison-generated files and compiled message catalogs.
If the Makefiles put these files in the build directory, then the release
script must move them to the source directory, and the Makefiles must be
able to handle both cases (of the files in the source directory, and of
them in the build directory) when installing or using the generated files.
(The only example currently moved by the release script is that of
compiled message catalogs; the others mentioned get built in the source
directory.)

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Ada build now requires gnatmake?

[Zack Weinberg]

On Tue, Dec 04, 2001 at 02:15:39PM -0500, Geert Bosch wrote:
> 
> On Tuesday, December 4, 2001, at 01:57 , Corey Minyard wrote:
> 
> >I just did an update and tried a bootstrap, and it seems that 
> >gnatmake is used to build the Ada compiler, specifically to build 
> >treeprs.ads, einfo.h, sinfo.h, and nmake.adb.  I thought 
> >bootstrapping was only supposed to require the compiler and 
> >gnatbind.
> 
> Yes, you're right. I have checked in a patch to einfo.ads and forgot
> to update the dependent sources, and sinced I have gnatmake on my
> system this didn't show up during bootstrap. I'll fix this and think
> about ways to ensure this doesn't happen again.

I thought the generated files had been taken out of CVS?

My offer to rewrite the generator programs in C stands.

zw

Re: Ada build now requires gnatmake?

[Geert Bosch]

On Tuesday, December 4, 2001, at 01:57 , Corey Minyard wrote:

> I just did an update and tried a bootstrap, and it seems that 
> gnatmake is used to build the Ada compiler, specifically to build 
> treeprs.ads, einfo.h, sinfo.h, and nmake.adb.  I thought 
> bootstrapping was only supposed to require the compiler and 
> gnatbind.

Yes, you're right. I have checked in a patch to einfo.ads and 
forgot to update
the dependent sources, and sinced I have gnatmake on my system this 
didn't
show up during bootstrap. I'll fix this and think about ways to 
ensure this
doesn't happen again.

   -Geert

Ada build now requires gnatmake?

[Corey Minyard]

I just did an update and tried a bootstrap, and it seems that gnatmake 
is used to build the Ada compiler, specifically to build treeprs.ads, 
einfo.h, sinfo.h, and nmake.adb.  I thought bootstrapping was only 
supposed to require the compiler and gnatbind.

-Corey