Re: Build using CMake

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.
> 

[PATCH] Missing NULL-allocation check for prevpath in ftp.c

Hi,

I found an instance in lib/ftp.c where the returned pointer from  
strdup() is not being properly checked. It is presently blindly being  
passed as a parameter to infof(), which would likely fault if strdup()  
were to return a NULL pointer.

I am not sure what the best failure mode is for this particular case,  
in terms of recovering from the error at the FTP level, but the  
attached patch fixes the crash.

Cheers,

/*  Andre Guibert de Bruet  * 436f 6465 2070 6f65 742e 2042 6974 206a */
/*     Managing Partner     * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */
/*   GSM: +1 734 846 8758   * 2055 4e49 5820 736c 6575 7468 2e00 0000 */
/* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */

Re: curl multi interface, every time added a new easy handle, need call curl_multi_perform to get socket descriptors?

On Tue, 31 Mar 2009, Sun Yi-Ming wrote:

> curl_multi_init
>
> curl_mult_setopt ( socket callback )
> curl_multi_add_handle
> curl_multi_perform
> get socket
> poll
>
> ...
> curl_multi_add_handle
> curl_multi_perform again
> get socket again
> poll
> ...
>
> it is somewhat urgly, IMHO.

I'm sorry but I don't understand what you're trying to say, or if there's a 
question in there I didn't spot it. Can you try to ask the question in a 
manner that is loud and clear to an old and grumpy man such as me?

--

-- 

  / daniel.haxx.se

Re: Build using CMake

Tetetest wrote:
> PD> I don't believe we could manage to do such a trick.
> 
> What makes you think so? Collaboration makes miracles.

:)

> 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.

From my little experience I expect this work would have to turn into
creating universal tool sooner than later.

--

-- 
Piotr Dobrogost
*** curlpp.org - c++ wrapper for libcurl ***

Re: Build using CMake

Hi Guen 

> Yang: I think you should proceed with your nmake tweaks

I respectfully listen your opinion, and in a friendly manner I tell
you that, for now, I won't follow it.

Contrary to what someone has said, Win32 lib/curl already can be built
out of the box in many ways and with a good bunch of tool chains. And
it is up to each one to chose the one that better suits his needs or
environment.

Something that is more frequently seen among people wanting to build
lib/curl with MSVC or for Win32 than those using other compilers or
platforms, is a lack of knowledge of the tools they are using.

I have no problem with that. Everybody comes to life knowing nothing,
no one knows everything, and many of us forget things.

What I really doubt is that any tool chain or build system will be
capable of fully replacing the most elemental required skills, no
matter if it is just a point and shoot, oops 'click', build system.

And what is worse, the more layers you put between a rooky and his
compiler, the more knowledge he will need to sort out even the most
trivial problem.

My full respect to those who try to learn. And much much more to those
who give back, in no specific order, advice, code, patches, bug
reports, tests, run auto-builds, provide binaries, provide new

Strange behaviour in multi interface

Re: [PATCH] Missing NULL-allocation check for prevpath in ftp.c

On Wed, 1 Apr 2009, Andre Guibert de Bruet wrote:

> I found an instance in lib/ftp.c where the returned pointer from strdup() is 
> not being properly checked. It is presently blindly being passed as a 
> parameter to infof(), which would likely fault if strdup() were to return a 
> NULL pointer.
>
> I am not sure what the best failure mode is for this particular case, in 
> terms of recovering from the error at the FTP level, but the attached patch 
> fixes the crash.

Thanks, I applied and committed. Possibly it should return a failure but since 
it can survive the strdup() failure I guess this is fine.

--

-- 

  / daniel.haxx.se

Re: Build using CMake

Hi Yang,
Yang Tse schrieb:
> Something that is more frequently seen among people wanting to build
> lib/curl with MSVC or for Win32 than those using other compilers or
> platforms, is a lack of knowledge of the tools they are using.
that's what I also thought often enough in the past.

> What I really doubt is that any tool chain or build system will be
> capable of fully replacing the most elemental required skills, no
> matter if it is just a point and shoot, oops 'click', build system.
I would express this more plain: without mouse these folks are lost; and
reading docu seems also not to be a habit of them.

> And what is worse, the more layers you put between a rooky and his
> compiler, the more knowledge he will need to sort out even the most
> trivial problem.
yup.

> As I have said, I'm not yet a cmake believer, nor openly detractor.
same here, and for me it would mean to start on making CMake work with
my NetWare cross compilers (which I started already a long time ago, but
due to other priorities had to push on halt).

> Do you know if CMake has a built-in Bourne shell interpreter?
I dont know; the only contact I had up to now with Cmake was in the past
with other projects (like libgd) as plain user of an existing build
system, and that I compiled latest self in order to follow up with the
help from the CMake developers who offered to help with adding NetWare
capability.

>> [...] working nmake makefiles which can be imported and converted to
>> project files by the IDE; then we document this and that's it.
> 
> Which IDE? MSVC's? From which VS version?
at least MSVC6 can, but I'm confident that newer versions can do too
(but not yet checked; Pierre might tell us...)
What I've also not checked yet is if newer MSVC versions ship with a
somewhat improved nmake? One of the most downsides of nmake is that I
didnt find a substitution rule to generate an object list from the *.c
files which I can get fine with including our Makefile.inc ...
Therefore I suggested to think about a gnu-make approach which I think
is totally acceptable - though at the cost that then the MSVC IDE cant
read the makefile anymore, and generate a project from it.

Gün.

Re: Strange behaviour in multi interface

On Wed, 1 Apr 2009, Alex Alex wrote:

> Now: if both connections are OK, i can continously "grab" http pages (they 
> are video frames, in my case) from the two urls. Unfortunately, If one of 
> the connection becomes idle, meanwhile, for an unknown reason select() 
> blocks for the used timeout at each cycle. Therefore, the other transfer 
> becomes slower, even if its connection is OK and it can give me data.

We've talked on IRC about this. I can't understand nor repeat this problem.

I've made a local test with one URL downloading 800MB from a local HTTP 
server while the other connect to an 'nc' that does nothing.

I've rerun the test multiple times now. It runs fine every time and there are 
no timeouts.

I think we need more help from you to repeat this.

--

-- 

  / daniel.haxx.se

Re: Build using CMake

Yang Tse wrote:

>> Yang: I think you should proceed with your nmake tweaks
> 
> I respectfully listen your opinion, and in a friendly manner I tell
> you that, for now, I won't follow it.

It's a great pity to hear this.
I hope you'll change your mind and we'll finish this makefile.

> Contrary to what someone has said, Win32 lib/curl already can be built
> out of the box in many ways and with a good bunch of tool chains. And

Above statement, being true, leads to nowhere.
You know current nmake makefile is very poor and that's why you started
to create a better one.
I know this too and that's why I wrote mine.
Everyone as soon as he tries to use current makefile will agree with this.

> Something that is more frequently seen among people wanting to build
> lib/curl with MSVC or for Win32 than those using other compilers or
> platforms, is a lack of knowledge of the tools they are using.

Maybe the knowledge of these two groups is comparable but the quality of
tools they use don't...
How can you know if it's not an inferior building process that creates
problmes for Windows' users?
I'm wondering how many Linux users were just ok to issue well known
three commands and not to think about build process at all.

> And what is worse, the more layers you put between a rooky and his
> compiler, the more knowledge he will need to sort out even the most
> trivial problem.

If it were true then autotools would have never succeeded.
If layers are good enough then 80% of users have no problems and the
rest 20% have tools to solve their problems.

It's a shame (I don't blame anyone) project this popular doesn't even
have descent makefile for Windows.
Portability and building problems are among main causes why other
languages (inferior in many other aspects) have gained so much
popularity over C/C++.
Decent build process should be integral part of every C/C++ project
because it's not integrated in the language.

--

-- 
Piotr Dobrogost
*** curlpp.org - c++ wrapper for libcurl ***