[llvm-commits] Need better way to build bison files

[Jeff Cohen]

Reid Spencer wrote:
> On Thu, 26 Apr 2007 07:16:31 -0700
>  Jeff Cohen <jeffc at jolt-lang.org> 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.
>
>>
>> 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.

> I'm interested because I'd like to fix this as part of the scons
> work.
>
> Reid.
>
>
>
>