What's best practice to incorporate Boost.Test in own project?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

What's best practice to incorporate Boost.Test in own project?

Mateusz Loskot
Hi,

I'm going to add Unit Tests to one of projects.
It's quite big project, so there will be many tests suits and cases.
The project build system is based on automake for Unix and nmake for
Windows.
I wonder what is the best practice to include Boost.Test
frameworks to my own project?

Currently I consider only Unit Test Framework.

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.

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

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.

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.

May be there are more possibilities I've not listed above, so please
share your ideas.

Thanks in advance for your comments.
Best regards
--
Mateusz Łoskot
http://mateusz.loskot.net

_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
--
Mateusz Loskot, http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|

Re: What's best practice to incorporate Boost.Test in own project?

Dmitry Bufistov
Mateusz Łoskot wrote:

> Hi,
>
> I'm going to add Unit Tests to one of projects.
> It's quite big project, so there will be many tests suits and cases.
> The project build system is based on automake for Unix and nmake for
> Windows.
> I wonder what is the best practice to include Boost.Test
> frameworks to my own project?
>
> Currently I consider only Unit Test Framework.
>
> 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.
>
> 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
>
> 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.
>
> 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.
>
> May be there are more possibilities I've not listed above, so please
> share your ideas.
>
> Thanks in advance for your comments.
> Best regards

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

_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: What's best practice to incorporate Boost.Test in own project?

Mateusz Loskot
Dmitry wrote:

> Mateusz Łoskot wrote:
>
>>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.
>
> Hello Mateusz,
> One obsevation concerning 3th approach for using boost.test framework.
> You just can include
> #include <boost/test/included/unit_test_framework.hpp>
> to your project and compile everything using your build system, isn't it?

Hi Dmitry,
But what about building Unit Test Framework library?
How should I provide building it? Using bjam (bjam would be requirement)
or own home-made makefiles for UTF?

Cheers
--
Mateusz Łoskot
http://mateusz.loskot.net
_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
--
Mateusz Loskot, http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|

Re: What's best practice to incorporate Boost.Test in ownproject?

Gennadiy Rozental
In reply to this post by Mateusz Loskot

"Mateusz Loskot" <[hidden email]> wrote in message
news:duf9bl$72t$[hidden email]...

> Hi,
>
> I'm going to add Unit Tests to one of projects.
> It's quite big project, so there will be many tests suits and cases.
> The project build system is based on automake for Unix and nmake for
> Windows.
> I wonder what is the best practice to include Boost.Test
> frameworks to my own project?
>
> Currently I consider only Unit Test Framework.
>
> 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.

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

> 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. User could use any make system
without probles. There is no additional options required Look on compilation
intrsuction in cvs. bjam really is not that complicated either. Just
something many not familiar with.

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

 Regards,

Gennadiy



_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: What's best practice to incorporate Boost.Test inown project?

Gennadiy Rozental
In reply to this post by Dmitry Bufistov

> Hello Mateusz,
> One obsevation concerning 3th approach for using boost.test framework.
> You just can include
> #include <boost/test/included/unit_test_framework.hpp>
> 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



_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: What's best practice to incorporate Boost.Test inown project?

Mateusz Loskot
Gennadiy Rozental wrote:

>>Hello Mateusz,
>>One obsevation concerning 3th approach for using boost.test framework.
>>You just can include
>>#include <boost/test/included/unit_test_framework.hpp>
>>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
--
Mateusz Łoskot
http://mateusz.loskot.net

_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
--
Mateusz Loskot, http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|

Re: What's best practice to incorporate Boost.Test in ownproject?

Mateusz Loskot
In reply to this post by Gennadiy Rozental
Hi Gennadiy,

Gennadiy Rozental wrote:

> "Mateusz Loskot" <[hidden email]> 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

_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
--
Mateusz Loskot, http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|

Re: What's best practice to incorporate Boost.Test inown project?

Dmitry Bufistov
In reply to this post by Mateusz Loskot
Mateusz Łoskot wrote:

> Gennadiy Rozental wrote:
>
>>>Hello Mateusz,
>>>One obsevation concerning 3th approach for using boost.test framework.
>>>You just can include
>>>#include <boost/test/included/unit_test_framework.hpp>
>>>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

_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users