[Bug 1702] Files .cvsignore'd but in the repository, some of them necessary to bootstrap

Fri Sep 17 17:42:05 UTC 2010

https://www.rtems.org/bugzilla/show_bug.cgi?id=1702

--- Comment #1 from Ralf Corsepius <ralf.corsepius at rtems.org> 2010-09-17 12:42:04 CDT ---
(In reply to comment #0)
> There are the following files contained in the CVS (HEAD) but .cvsignore files
> say they should be ignored.
> 
> At least some of them result in errors during "bootstrap" run if they are
> missing
> 
> c/src/ada-tests/aclocal/prog-gnat.m4
> c/src/lib/libbsp/lm32/milkymist/autom4te.cache
> c/src/lib/libbsp/m68k/genmcf548x/autom4te.cache
> c/src/lib/libbsp/mips/hurricane/include/coverhd.h
> c/src/lib/libcpu/bfin/autom4te.cache
> c/src/lib/libcpu/sparc64/autom4te.cache
> c/src/lib/libcpu/sparc64/autom4te.cache
> c/src/lib/libcpu/sparc64/autom4te.cache
autom4te.caches are not supposed to be in CVS and to be in .cvsignore.

The coverhd.h and the prog-gnat.m4 cases would require to be looked in.

> contrib/crossrpms/autotools/rtems-4.11-autoconf.spec
> contrib/crossrpms/autotools/rtems-4.11-automake.spec
These are supposed to be in CVS and not to be in .cvsignore.

They once had been in .cvsignore and have been removed from .cvsignore
recently.

> contrib/crossrpms/mingw32/i686/i686-pc-mingw32-binutils-helper.spec.in
> contrib/crossrpms/mingw32/i686/i686-pc-mingw32-curses-helper.spec.in
> contrib/crossrpms/mingw32/i686/i686-pc-mingw32-expat-helper.spec.in
> contrib/crossrpms/mingw32/i686/i686-pc-mingw32-gcc-helper.spec.in
> contrib/crossrpms/mingw32/i686/i686-pc-mingw32-libs-helper.spec.in
> contrib/crossrpms/mingw32/i686/i686-pc-mingw32-readline-helper.spec.in
> contrib/crossrpms/mingw32/i686/i686-pc-mingw32-termcap-helper.spec.in
> contrib/crossrpms/mingw32/i686/i686-pc-mingw32-w32api-helper.spec.in
> contrib/crossrpms/mingw32/i686/i686-pc-mingw32-zlib-helper.spec.in
These are supposed to be in .cvsignore and not in CVS.

> contrib/rtemsrpms/INSTALL
This is dead code. rtemsrpms is dead.

This code should be removed.

> doc/common/setup.texi

No idea about this one.

> I'm trying to track my changes in a VCS locally and ignoring all files
> .cvsignore tells me to ignore results in problems with "bootstrap" that don't
> occur when these files are present.

I'd assume you to be facing issue with your VCS and/or your VCS import process.

At least some of the files you refer to above have either been in .cvsignore
and removed from .cvsignore, while others have been missing.

Others would require to look into.

> If these files are missing (which they are if I'm ignoring everything
> .cvsignore ignores), instead of the usual messages that only mention something
> being "installed" or m4 files being unchanged:

> $ ./bootstrap -p 
> 
> runs normal ...
> 
> $ ./bootstrap
> ./c/src/ada-tests
> aclocal: couldn't open directory `aclocal': No such file or directory
> configure.ac: no proper invocation of AM_INIT_AUTOMAKE was found.
> configure.ac: You should verify that configure.ac invokes AM_INIT_AUTOMAKE,
> configure.ac: that aclocal.m4 is present in the top-level directory,
> configure.ac: and that aclocal.m4 was recently regenerated (using aclocal).
> mptests/mp01/node1/Makefile.am: installing `./depcomp'
> /home/peer/rtems-4.10/share/automake-1.11/am/depend2.am: am__fastdepCC does not
> appear in AM_CONDITIONAL
> /home/peer/rtems-4.10/share/automake-1.11/am/depend2.am:   The usual way to
> define `am__fastdepCC' is to add `AC_PROG_CC'
> /home/peer/rtems-4.10/share/automake-1.11/am/depend2.am:   to `configure.ac'
> and run `aclocal' and `autoconf' again.
> /home/peer/rtems-4.10/share/automake-1.11/am/depend2.am: AMDEP does not appear
> in AM_CONDITIONAL
> /home/peer/rtems-4.10/share/automake-1.11/am/depend2.am:   The usual way to
> define `AMDEP' is to add one of the compiler tests
> /home/peer/rtems-4.10/share/automake-1.11/am/depend2.am:     AC_PROG_CC,
> AC_PROG_CXX, AC_PROG_CXX, AC_PROG_OBJC,
> /home/peer/rtems-4.10/share/automake-1.11/am/depend2.am:     AM_PROG_AS,
> AM_PROG_GCJ, AM_PROG_UPC
> /home/peer/rtems-4.10/share/automake-1.11/am/depend2.am:   to `configure.ac'
> and run `aclocal' and `autoconf' again.
> samples/Makefile.am:5: HAS_MP does not appear in AM_CONDITIONAL
> samples/base_mp/node1/Makefile.am:10: EXPADA does not appear in AM_CONDITIONAL
> samples/base_mp/node2/Makefile.am:10: EXPADA does not appear in AM_CONDITIONAL
> Makefile.am:6: HAS_MP does not appear in AM_CONDITIONAL
> Makefile.am: installing `./INSTALL'
> Makefile.am: required file `./NEWS' not found
> Makefile.am: required file `./README' not found
> Makefile.am: required file `./AUTHORS' not found
> Makefile.am: installing `./COPYING' using GNU General Public License v3 file
> Makefile.am:     Consider adding the COPYING file to the version control system
> Makefile.am:     for your code, to avoid questions about which license your
> project uses.
> grep: Makefile.in: No such file or directory
> ./c/src/lib/libbsp/arm/csb336
> ./c/src/lib/libbsp/arm/csb337
> ./c/src/lib/libbsp/arm/edb7312
> ./c/src/lib/libbsp/arm/gba
> ./c/src/lib/libbsp/arm/gdbarmsim
> ./c/src/lib/libbsp/arm/gp32
> ./c/src/lib/libbsp/arm/gumstix
> ./c/src/lib/libbsp/arm/lpc24xx
> ./c/src/lib/libbsp/arm/lpc32xx
> ./c/src/lib/libbsp/arm/nds/tools
> ./c/src/lib/libbsp/arm/nds
> ...
> 
> From here it looks normal again.
> 
> I don't know if these messages can be ignored but they don't make me confident.

None of these messages is supposed to be ignored, but also no idea what is
going on for you (I can't reproduce this issue).

> BTW: I'm running
> 
> triton:/usr/home/peer $ automake --version
> automake (GNU automake) 1.11.1
> triton:/usr/home/peer $ autoconf --version
> autoconf (GNU Autoconf) 2.65
2.65 is known to suffer from serious bugs. I haven't notice them to hit rtems
yet, but I strongly recommend to upgrade to 2.67 (2.66 was a "brown paper bag",
entirely unusable).

BTW1: Which OS are you using? Wasn't it you who once mentioned to be facing
issues with BSD's shell?

I am not seeing any of the issues your observe, which makes me think you may
also be facing more shell related issues.

BTW2: There recently was a CVS tag screw up.
Try cvs up -dP -A (on CVS-HEAD) rsp. try a fresh checkout.

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.