[geos-devel] [GEOS] #556: Build error using cmake: ../geos_svn_revision.h: No such file or directory

[Mateusz Loskot]

On 25 June 2012 15:08, Sandro Santilli <strk at keybit.net> wrote:
> On Mon, Jun 25, 2012 at 01:05:59PM +0100, Mateusz Loskot wrote:
>> On 25 June 2012 13:01, Sandro Santilli <strk at keybit.net> wrote:
>> > On Mon, Jun 25, 2012 at 10:59:31AM -0000, GEOS wrote:
>> >
>> >>  Simply, I'd suggest to avoid making the whole process unnecessarily obscure.
>> >
>> > What's obscure about ./configure && make ?
>>
>> IMO, make should not generate intermediate env/platform/user-specific headers.
>> It's autoconf's job.
>>
>> > The most obscure thing I see is "cmake" invocation, to be honest.
>>
>> cmake invocation is equal to ./configure step.
>>
>> > There's no need to explicitly invoke the svn file generator,
>> > it's all taken care of by "make" ...
>>
>> I understand make can do it and make can (almost) do whatever you want,
>> but that is not the point.
>
> My point is that the SVN revision string serves the purpose of knowing
> which SVN revision you're actually using

Yes, it's clear.

> It's very weak to depend on the discipline of the builder to always run ./configure (or cmake)
> after each and every SVN update, so the result would often be an outdated
> revision string in reported issues.

On the contrary, depending on the ./configure is actually the strength
of the solution.
Every svn update should be followed by ./configure, then make,
and skipping ./configure after svn update should not be supported whatsoever.

The svn update can bring lots of things changes at different levels
and users shall never
assume build configuration, templates of generated headers, and other
volatile stuff
will stay untouched. After svn update, all dangling headers, generated
by previous
calls to ./configure should be regenerated.

Any workflow within the development version of source code different than
svn update && ./configure && make
should neither be encouraged to follow, nor supported.

Also, geos/version.h should have something like
#define GEOS_REVISION  @GEOS_REVISION@
substituted during boostrap.

My 5 cents.

> By having "make" do that we're guaranteed that the revision number is
> always up to date.

This is not a solution, but obscure hack that interferes with typical
build steps.

My 2 cents.

> May I suggest you just add the script invocation and if any compatibility
> problem arises we try to fix it ?

Sure.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net