[GRASS-dev] Re: [GRASS-windows] windows qgis-grass: make grass build with vc or keep a separate qgis-grass mingw build?

[G. Allegri]

Anyway, IIUC Glynn and Jurgen:

 the problem on mixing MSVC and MinGW built things (at C level) is
just a problem of a clean memory management (malloc/free). So, my
question is: would changing the build system (GNU make -> cmake) solve
this? Or they're unrelated things?

2009/3/27 G. Allegri <giohappy at gmail.com>:
> Ok Markus. I'm sorry for pressing... My hope is to do not have a
> broken community around this issues. I would like to come to a common
> thought, and work for a coherent and clear roadmap. Probably it's me
> (and the users) that don't have it clear, while it is for all of the
> developers: who is doing what and in which direction?
>
> From an old Qgis log, Frank has explained that his dream is to have
> everything coherently packaged under osgeo4w, and hopefully to be able
> to extract standalone builds from it  (ie, qgis, grass, qgis+grass).
> This viewsight probably would be the best from the users point of
> view. The best would be to have osgeo4w setup, and standalone NSI
> installers... but I'm talking with no experience on what this would
> require, or if it's possible.
>
> I hope the discussion will go on.
>
>
> 2009/3/27 Moritz Lennert <mlennert at club.worldonline.be>:
>> On 27/03/09 10:30, G. Allegri wrote:
>>  >  In any case the questions remain:
>>>
>>>  1 -  continue to build grass with MingW?
>>>      1a: build it against MinGW built libs (not osgeo4w)?
>>>      1b: build it against vc built libs (osgeo4w)?
>>>
>>> 2 - build Qgis with vc (osgeo4w) and solve the bindings problems with
>>> Grass: 1a or 1b?
>>
>> IIUC what Markus and Glynn are trying to get at: these questions seem to be
>> a bit quick without having clarified where the problem actually lies. Is it
>> with the GRASS source code, is it with the choice of build system or is it
>> with the osgeo4w tool chain. Jürgen says it's mainly the choice of
>> configure/make which is at stake, Glynn seems to contest that. So before we
>> haven't clearly identified where the problems actually lie, we cannot answer
>> the above questions.
>>
>> Moritz
>>
>