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

[Reid Spencer]

On Thu, 26 Apr 2007 08:03:48 -0700
 Jeff Cohen <jeffc at jolt-lang.org> wrote:
>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.

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