Hello Mateusz, One obsevation concerning 3th approach for using boost.test framework. You just can include #include to your project and compile everything using your build system, isn't it? --dima

I wouldn't recommend using this option on a permanent basis. You don't know what kind of hardware users are using and how slow above solution would be. Also this solution still leave you with boost dependency (particular version of it). So there is no much with in comparison with rebuilt library. Gennadiy

Mateusz Łoskot wrote:

Gennadiy Rozental wrote:

...

...

Hello Mateusz, One obsevation concerning 3th approach for using boost.test framework. You just can include #include to your project and compile everything using your build system, isn't it? --dima

I wouldn't recommend using this option on a permanent basis. You don't know what kind of hardware users are using and how slow above solution would be. Also this solution still leave you with boost dependency (particular version of it). So there is no much with in comparison with rebuilt library.

That's clear for me. Thank you

Cheers Ups, sorry for bad avices and misunderstanding(( Shame on my gray head, --dima

Hi Gennadiy, Gennadiy Rozental wrote:

"Mateusz Loskot" wrote:

...

I see following possibilities:

1. Boost libraries are installed from official release (precompiled or compiled by user) Makefiles for my project try to detect if Boost exists and link to Unit Test Framework librar. Here Boost has to be listed in compilation requirements of my project.

This option is more or less safe. Since:

1. Boost is installed in many places now 2. Your own code is quite possibly will have to use boost itself.

Don't forget though that you will depend on some particular version of boost. Not just any available.

Yes. I think this is the only disadvantage I can see in this solution.

...

2. Boost.Test libraries in binary form are included to my project tree and shipped together. So there is no requirement to have complete Boost installed, because test can link to UTF library already present

This option is probable safest. Becuse you doesn't require boost dependencies and doesn't require particular version of boost installed. On the other hand it will enlange the size of you deliverables.

Yes, you're right.

...

3. Include Boost.Test source code and allow user of my project to build UTF library on his own. Here I expect some problems with bjam/makefiles incompatibility. So, bjam would be required on user's platform. Simply, this solution seems to be quite confusing for user.

UTF building doen't require that much effort.

Yes, I think so. I learned it recently, so I see there should not be a problem to write makefile to build UTF lib, as well as create VC++ project file (what I've already done easily).

User could use any make system without probles. There is no additional options required Look on compilation intrsuction in cvs.

That's right.

bjam really is not that complicated either. Just something many not familiar with.

Huh! I've heared something different :-) But I'm not going to discuss bjam here.

...

I'd like to know your comments about which solution is best and what are possible traps hidding. Regarding the 1 solution I think there may be possible problem with using incorrect Boost.Test version. The second one involves additional work for overall projct maintenance.

You right on both counts. I would supply prebuilt UTF binaries as a separate optional. delivarable. Happy owners of proper boost version could use their UTF (build one first one way or another). The rest could download one you supply.

You're recommendation sounds very good. I think I'll stick to it. Thank you -- Mateusz Łoskot http://mateusz.loskot.net