Hi,

Tetetest schrieb:
> Hello Piotr,
>
> Tuesday, March 31, 2009, 8:34:05 PM, you wrote:
>
> PD> tetetest tetetest wrote:
>
>>> By the way, we need not keep two separate build chains. It is far more
>>> convenient to use some kind of 'cmakify' script that will parse
>>> existing autoconf files and create CMakeLists and feature tests based
>
> PD> I don't believe we could manage to do such a trick.
>
> What makes you think so? Collaboration makes miracles.
>
> Autoconf files do not come from another galaxy - they are maintained
> by live people. CMake build system can do exactly the same checks as
> autoconf script, so conversion between autoconf and cmake is, most of
> the time, the question of extracting pieces of text, re-formatting
> them by some rule and inserting them into some other files at certain
> locations.
>
> Some pieces of text in autoconf files may have similar structure, but
> completely different semantics (I am theoretizing here, for I have no
> examples at hand). To help the script decide how to convert the
> particular piece of text, we may add special comments to the autoconf
> files. Some hard-to-parse constructs may be simplified for the script.
>
> The aim is not to write a "universal autotools-to-cmake translator" -
> we just need a tool that extracts relevant checks from autotool
> buildchain and stuffs them into cmake one.
exactly, and that sounds good.
I think we have enough discussed by now; Daniel has agreed that we add
CMake files to our CVS, so I think we should start now so that we see
somthing working on....
Tetetest has some good ideas, and if he comes up with a script which
automagically can create CMakefiles + can integrate with our release
script then that would be a very good start. Futher more we have at
least 3 folks I count here who want to see such, and who use MSVC,
MinGW32, and Linux. That would also be a very good start. The first
submission does not need to be perfect nor does it need to support each
and every platform under the sun - if it would be an alternative build
method for MSVC only but easier to use that would already be a very good
start, and we can add more platforms over the time.
And lets stop about removing things before we even have seen _any_ CMake
stuff which can actually build at least for one platform _better_ than
what we currently have.
Tetetest: where must this script you speak of live in libcurl source
tree? any special place? What directories must be created for the
CMkaefiles? Since you have at least something working already please
start, and post something here which we can bring into CVS, and when you
do so perhaps best is to start a new thread, and use this then _only_
for discussions about this script and its results, what's lacking, and
what needs to be improved. Please, if possible, post a 'diff -u' against
recent CVS.
Yang: I think you should proceed with your nmake tweaks - the only thing
I see us dropping soon may be the crazy MSVC project files, and these in
favour of working nmake makefiles which can be imported and converted to
project files by the IDE; then we document this and that's it - I
believe that we can require this knowledge and ability from a MSVC
developer.

thanks, Gün.
Received on 2009-04-01