Bug 1381 – Moving `boost`-related configuration to main wscript

Bug 1381 - Moving `boost`-related configuration to main wscript


Summary:	Moving `boost`-related configuration to main wscript

Status:	RESOLVED DUPLICATE of bug 1562

Product:	ns-3
Classification:	Unclassified
Component:	general
Version:	ns-3-dev
Hardware:	All All

Importance:	P5 normal
Assigned To:	ns-bugs

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2012-02-29 21:00 EST by Alex Afanasyev
Modified:	2013-04-26 17:56 EDT (History)
CC List:	0 users

See Also:

Attachments
patch (2.46 KB, patch) 2012-02-29 21:06 EST, Alex Afanasyev	Details \| Diff
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Alex Afanasyev 2012-02-29 21:00:02 EST

There is a problem when two different modules require different boost
libs.  

Right now, openflow module checks for boost and requires "signals" and "filesystem" libraries.  I have a custom module that needs another boost libraries and it is impossible to specify them without totally disabling the openflow module.

The attached patch solves the problem by moving boost checking to the main wscript.

Comment 1 Alex Afanasyev 2012-02-29 21:06:48 EST

Created attachment 1346 [details]
patch

Comment 2 Tommaso Pecorella 2012-03-14 20:58:20 EDT

The proposed patch is not totally satisfactory imho.

The problem is that, if I understood it right, boost will be checked against 
all the boost libs required by both modules. Hence if just a subsets is 
present, no boost-dependent module will be built, even if its requirements are 
met.

In other words:
OpenFlow needs Boost's "signals" and "filesystem"
Your module requires Boost's "iostreams" and "regex"
If just ONE of those is missing, neither OpenFlow or your module will be built.

Not really a nice behaviour, isn't it ?

I do agree we need a fix, however the Boost check should be more flexible.

T.

Comment 3 Alex Afanasyev 2013-04-26 17:56:19 EDT


*** This bug has been marked as a duplicate of bug 1562 ***