[geos-devel] Problem with building 3.0.0rc

[Sean Gillies]

Same here.

The mkinstalldirs script appears to be buggy on this particular
platform. One shift too many. Strangely, the 3.0rc builds fine on
another Ubuntu 6.10 i686 of mine. Same bash version even.

I suppose I could try to fix mkinstalldirs, but it seems like it should
be simpler and more foolproof for the build to ignore swig/python
alltogether unless it is explicitly enabled.

Sean

Paul Ramsey wrote:
> The tail of my ./configure looks like this, what does yours look like?
> 
> config.status: creating swig/geos.i
> config.status: creating swig/Makefile
> config.status: creating swig/python/Makefile
> config.status: creating swig/python/tests/Makefile
> config.status: creating swig/ruby/Makefile
> config.status: creating swig/ruby/test/Makefile
> config.status: creating tests/Makefile
> config.status: creating tests/bigtest/Makefile
> config.status: creating tests/unit/Makefile
> config.status: creating tests/tut/Makefile
> config.status: creating tests/xmltester/Makefile
> config.status: creating tools/Makefile
> config.status: creating tools/geos-config
> config.status: creating source/headers/config.h
> config.status: source/headers/config.h is unchanged
> config.status: creating source/headers/geos/platform.h
> config.status: source/headers/geos/platform.h is unchanged
> config.status: executing depfiles commands
> Swig: false
> Python: false
> Ruby: false
> 
> 
> On Dec 28, 2007, at 7:44 AM, Sean Gillies wrote:
> 
>> Charlie Savage wrote:
>>>
>>>
>>> Sean Gillies wrote:
>>>> I'm encountering a problem with the 3.0 release candidate that blocks a
>>>> build on my Ubuntu 6.10 i686.
>>>>
>>>> "configure --prefix=/tmp; make; make install" bails out here:
>>>>
>>>> I don't understand why the install-pkgpythonPYTHON target is attempted
>>>> when I haven't enabled the swig python bindings. Any idea what's up
>>>> here?
>>>
>>> Thinking about this more, I think the way this was setup is to run SWIG
>>> if the bindings file (*.cxx) is older than any changes to the SWIG
>>> interface files (*.i).
>>>
>>> That should not be the case unless you've modified the interface files,
>>> or they've somehow been modified in SVN since the generation of the
>>> *.cxx files.
>>>
>>> Charlie
>>>
>>
>> I wonder then if I'm experiencing an unintended side effect. I've not
>> enabled swig python or ruby and swig is not run to produce wrappers
>> (good), but the machine still steps into swig/python/Makefile and
>> executes targets therein, even attempting to byte compile nonexistant
>> modules.
>>
>> IMO, unless swig/python is explicitly enabled, make should skip that
>> branch of the tree. Or am I overlooking something?
>>
>> Sean
>>