On Thu, 26 Apr 2007 08:03:48 -0700 Jeff Cohen <[EMAIL PROTECTED]> wrote: >Reid Spencer wrote: >> On Thu, 26 Apr 2007 07:16:31 -0700 >> Jeff Cohen <[EMAIL PROTECTED]> wrote: >>> My nightly tester failed last night for the following reason: >>> >>> cvs update: conflicts found in lib/AsmParser/llvmAsmParser.cpp.cvs >>> C lib/AsmParser/llvmAsmParser.cpp.cvs >>> >>> >>> Needless to say, the tester is not in the business of modifying >>> source code, but it manages to modify a file under cvs control anyway >>> and do so in a way that conflicts with subsequent changes. >> >> The nightly tester doesn't do "update", only "checkout", so I'm >> not sure how you got this last night. Sure this didn't come from >> your wrapper script? >Yes, it came from my wrapper script, which updates the LLVM tree used to build >llvm-gcc. This is an unavoidable task in running the nightly tester unless I >want everything using C/C++ to fail.
Yes, I understand, but it is also incumbent upon your wrapper script to make sure it doesn't fail. Try removing the *.cvs files in utils/TableGen lib/AsmParser and tools/llvm-upgrade before you do the update. This should avoid the problem. To ensure your bison is used for the build, touch your .y files as well. >> >>> >>> The way bison files are managed needs to be fixed so that files under >>> cvs control do not change unless a human wants them to change. >> >> >> That is exactly the current situation. The problem is that >> someone checked in a new version of the .cvs file while you also >> had uncommitted changes (from running bison locally). > >No, that is not the current situation. No human wanted those files to change, >unless the mere act of building LLVM constitutes consent to modify files under >cvs control. In that case, why not have it auto-commit the changes as well? >Absurd? Exactly. > >> However, I agree in general that these files are awkward to deal >> with. There's only two solutions I can think of: (a) rewrite the >> parser to be recursive descent and avoid use of bison, or (b) >> require all platforms to have bison. Neither are attractive. > >Not true. I handle this with Visual Studio. Bison is not required, nor does >the act of running it alter a file under source control. It isn't hard to do. > Just don't modify the *.cvs files automatically. Have a separate makefile >target to do that. Will people sometimes forget to do that? Yes. And >someone will notice and point it out. And no one will have to deal with bogus >conflicts again, or have to prevent modified *.cvs files from being committed >when no changes were made to any *.y files, yet they got modified anyway. That's not a bad idea. You'll need to convince Chris, however :) > >> I'm interested because I'd like to fix this as part of the scons >> work. >> >> Reid. >> >> >> >> > _______________________________________________ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
