[BuildTools] Problems with commit_new_release

[Andreas Waechter]

Laci and I just committed a change in BuildTools/trunk.  Please try if 
that works.

On Mon, 29 Oct 2007, Laszlo Ladanyi wrote:

> Just change the find command to this:
>
> conf_ac_files=`find . -name configure.ac | grep -v ThirdParty`
>
> Then all the ThirdParty stuff is excluded so the script should run fine. 
> Later we can try to find a more permanent solution.
>
> --Laci
>
> On Mon, 29 Oct 2007, Ted Ralphs wrote:
>
>> Laszlo Ladanyi wrote:
>>> 
>>> 
>>> On Mon, 29 Oct 2007, Andreas Waechter wrote:
>>> 
>>>> Hi Ted,
>>>> 
>>>>> I used the new scripts for preparing a new release of SYMPHONY this
>>>>> morning and there seems to be a few problems with the commit_new_release
>>>>> script. I have not spent enough time to extract all the details of what
>>>>> happened, but wanted to throw this out there, since I know there are a
>>>>> number of folks preparing releases right now. The first glitch I noticed
>>>>> was that the script exited after the following error:
>>>>> 
>>>>> svn: 'ThirdParty/Glpk/glpk/configure.ac' is not a working copy
>>>>> svn: Can't open file 'ThirdParty/Glpk/glpk/configure.ac/.svn/entries':
>>>>> Not a directory
>>>> 
>>>> This appears to be a problem with subversion.  Maybe there was a
>>>> problem communicating with the server...  I have seen this before
>>>> myself, I think, and I simply had to check out a new copy.
>>> 
>>> I think Ted is right. The failure stems from glpk having its own
>>> configure.ac file. It is found by the find command, then it's patched
>>> (which, as you correctly say below, is fine) and finally an 'svn diff
>>> configure.ac' is done to it. svn rightfully says that it is not a
>>> working copy, and since there was an error, returns a non-zero exit
>>> value, and after that the script aborts.
>>> 
>>> The simplest way to fix it is to first check whether the configure.ac
>>> file is managed by subversion or not.
>> 
>> Ah yes, I see now, too. I didn't put this together before. To solve this
>> problem and stop from patching all the configure.ac files for external
>> dependencies, can't we just only look for the configure.ac file in the
>> base directory and then the ones in the subdirectory having the same
>> name as the project? Don't all projects have this structure? Or not? I'm
>> not as good as you guys in implementing all the fancy script stuff :),
>> but shouldn't we be able to pull the name of the project out from
>> somewhere and just do find in the subdirectory only?
>> 
>> Cheers,
>> 
>> Ted
>> -- 
>> Dr. Ted Ralphs
>> Associate Professor
>> Industrial and Systems Engineering
>> Lehigh University
>> (610)758-4784
>> tkralphs at lehigh.edu
>> www.lehigh.edu/~tkr2
>> 
>