Andrei wrote:

> Well, splitting intermediate and target stuff is mostly a matter of
> taste. But if I do so, I'd rather leave intermediate stuff where it is
> now and make a separate dir (say, 'lib') for the target stuff.

As you wish.

> Whether you should fix level 4 warnings depends on the concrete case and
> on your own paranoic level ;).

My proposition to set warning level to 4 says something about my paranoic level, I think :)

>> I don't know why you defined this
>> #define BUILDING_CURLPP 1
>> in config.win32.h? This should only be defined when building curlpp. Did I missed something?
>
> Did I ?

No you didn't :) It was there already I guess. Sorry.

>> We should rename curlpp.sln and curlpp.vcproj files to curlpp.vc8.sln and curlpp.vc8.vcproj and add curlpp.vc9.sln and curlpp.vc9.vcproj files when they'll be ready.
>
> Yes and no.
> Yes - it is easier for the MSVS library user
> No - because the developers will have to maintain project file for each
> MSVS version which are 99% the same.
> I suggest the trade-off solution: until the project/solution files are
> back compatible, we keep the lowest version and let the Visual Studio
> to convert them if necessary to a higher version.

Yes and no. :)
I think we could agree that supporting the last and the second to last version of VC is enough and covers 80% of VC users.
I find it very annoying to have to create project file for library which I'm sure had been already used by many users of the same IDE long before me...
We should take into consideration MSVC is not GCC and new versions don't come out very often.
Also I guess 80% of developers using VC use only one version of VC. They won't have to maintain different project files and will be glad to load ready made project and start using library as soon as possible.

> I dunno if VC8 projects are convertible to VC9 but if yes, I'd leave it in 8.

They are.

>> The last but not the least we should add support for compiling with OpenSSL.
>>
> I did not look at it, but I think this should be handled on libcurl level...

For the most part yes. But how is it that there is no SSL macro in cURLpp saying if libcurl was build with SSL or without? Shouldn't cURLpp interface be different in both situations?

> Also please note I just committed a change to curlpp: OptionSetter.cpp
> is now included in MSVC project.

I noticed. I had to include it myself when I was using cURLpp without this fix.

> And one more thing: *currently* I am not using curlpp in any project. I

No problem. Just start any project where it could be used and start coding :)

> project but it will happen not earlier than beg. 2009. When it happens,
> it will be a real case for curlpp, hope I will not regret my choice ;)

By the time you will have needed this we have to make it better and ready for you and others to use :)

Regards
Piotr Dobrogost
_______________________________________________
cURLpp mailing list
cURLpp_at_rrette.com
http://www.rrette.com/mailman/listinfo/curlpp
Received on 2008-11-11