cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: sukender: curl/tests/libtest CMakeLists.txt,NONE,1.1

From: Sukender <suky0001_at_free.fr>
Date: Tue, 07 Apr 2009 11:15:49 +0200

Le Tue, 07 Apr 2009 09:37:57 +0200, tetetest tetetest <tetetest_at_rambler.ru> a écrit:

> * Daniel Stenberg <daniel_at_haxx.se> [Mon, 6 Apr 2009 23:18:04 +0200
> (CEST)]:
>> On Mon, 6 Apr 2009, cvs_at_labb.contactor.se wrote:
>>
>> > SET(noinst_PROGRAMS
>> > lib500 lib501 lib502 lib503 lib504 lib505 lib506
>> > lib507 lib508 lib510 lib511 lib512 lib513 lib514 lib515
> lib516
>>
>> Here's another list that will need future updates all the time as this
>> is a
>> list that changes frequently. I don't think that's a good approach. It
>> is
>> doomed to lag behind forever... Here too we should use a single list
>> that can
>> be used for (included by) all build systems.
>
> There are more things like that:
> - lists of headers that 'configure' checks for;
> - curl-specific tests (the ones that are in m4/curl-*.m4 files);
> - Of course, lists of files and headers;
> - (most obvious thing:) curl version numbers.
>
> I think I can write perl scripts that will parse existing autotools
> files and update the CMake buildchain files. The scripts can be invoked
> from... ehm... from the same place where 'mkhelp.pl' is called. :)
>
> --
> tetetest tetetest.
>

[THIS IS A REPOST because my mailer had an error. Sorry if you get the mail twice.]

Hi Daniel,
Tetetest and you are both right.
However I must admit the work may not go as fast as you want, but I clearly don't really have much time.

Moreover, there are still problems building tests, so I think the list will be "generalized" in a "Makefile.inc" after problems have been solved. Here are my questions:

1. In tests/server/Makefile.am, there is a "useful = ..." with several source files. What happens here is that you may have, for example "lib/mprintf.c" included in the build whereas it was already in libcurl. So what? Well, Bill Hoffman reported a link error: "curl_mprintf already defined in mprintf.c.obj" (Win32 I guess). So why is this file there? Must it be included with a specific condition? Or have you got another idea/clue/thing to say?
Same thing with "curl_strnequal already defined in strequal.c.obj".

2. Similarily to this, Bill reported an "unresolved external symbol _Curl_hash_destroy referenced in function _test" and another with "Curl_mk_dnscache" (Building lib558)... I guess this is a file that must be included with a specific condition... isn't it?

-- 
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
Received on 2009-04-07