"Paul A. Bristow" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> In trying to be virtuous and test everything compiled in strict mode as I
write
> it, I am finding myself thwarted by BOOST minimal_test otherwise excellent
test
> system.
>
> I aim to compile and test all my code with
"Rob & Lori" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> For those of you who are unfamiliar with pluggable factories, I suggest
> reading the following C++ Report article:
> http://www.adtmag.com/joop/crarticle.asp?ID=1520
I have generic implementation of plugable factory in va
> BTW, after looking at the implementation I was a bit disappointed to
> see two copies of the storage. It seems to nullify one
> important reason for using variants (space savings), and it generates
> more code than a single-storage version. I know you had some rationale
for
> that but I don't r
> Boost.Config uses _POSIX_VERSION to determine wether sigaction()
> is available. The presence of _POSIX_VERSION doesn't indicate
> wether the POSIX API has actually been enabled.
>
> If we want to use Boost.Config to take care of this then
> Boost.Config also has to check wether POSIX has been en
My understanding is that Boost.Config should take care about these issues.
Boost.Test rely on BOOST_HAS_SIGACTION flag. It should not be defined in
case if there is no support for POSIX interfaces. Could you report the value
of that flag in case of compilation failures you are expiriencing.
Gennad
> I read all of the previous discussion of this on the boost list and did
not
> find any good arguments against mine.
> 1) Pointer specific features have been removed for smart_handle. Both
> implicit and explicit type coercion features are gone as are operators *
and ->.
I do not see anything w
Hi,
I do not want to start this discussion all over again, but in the reasoning
you presenting I did not find anything new to justify another "smart
pointer" like component. It's only one simple case of PBSP and I do not see
any reason not to use it.
Gennadiy.
_
I remember that there are 2 types of separators in boost tokenizer:
returnable and ignorable. Set "-" as returnable separator, and "," as
ignorable. It should give you all the information you need.
Gennadiy.
"lattice" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> If we print some
> > There is BOOST_CHECK_PREDICATE
> >
> Yes, I know.
> My point was that with BOOST_CHECK_EQUAL_NUMBERS() the test library
> could output something readable of the form:
>
> "numbers x and y are not approximately equal"
>
> It could even add to the output something of the form:
>
> " according to
> Could you please be more specific about which Boost.Test features you
think
> should remain and which should be removed or modified? I'm having trouble
> relating the discussion to the actual Boost.Test public interface.
>
> Thanks,
>
> --Beman
The only thing I propose to change is to prohibit
"Beman Dawes" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> test_fp_comparisons has been failing for a long time. The issue has to do
> with how much tolerance to allow for rounding errors.
>
> The close_at_tolerance algorithm calculates tolerance as follows:
>
> n*std::numeric_
Hi,
I am having problems with subject test with Metrowerks compiler. I was able
to minimize the issue to the following snippet:
#include
#include
template
inline void
print( std::ostream& ostr, T const& t, long ) { ostr << t; }
template
inline void
moo( std::ostream& ostr, T const& t ) { print
"Daryle Walker" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> While writing some other code, I checked out how some of the macros in
> Boost.Test are implemented. The BOOST_CHECK_THROW and
> BOOST_CHECK_EXCEPTION macros flag when an intentional exception was
> missed and when the
Fixed.
Thanks,
Gennadiy.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[...]
>BOOST_CHECK_CLOSE( 1.49012e-8, 0.0, 1e-6 );
[...]
> error in "BOOST_CHECK_CLOSE_test": test 1.49012e-8 ~= 0.0 failed
[1.49012e-008 !~= 0 (+/-1e-006)]
This is how it's supposed to be. Check floating pointer comparison algorithm
description for more detailes and links to references. The g
> * event driven xml file parsing (sax)
I did not really used DOM to much. I may have some comments on SAX though.
Perfunctory look on your interfaces left me wondering: who does it differ
from xerces? Still xmlChar type, tons of virtual functions. We are in modern
C++ world. No need to promote su
> What I meant is that the files contain data specific to your own
> programing environment (there are absolute filesystem paths in the 7.1
> project files for example). It's the reason why I was suggesting that it
> may be a mistake with CVS. If there is no mistake and if the files are
> really u
> Are the directories "libs/test/build/msvc??_proj" really necessary? Or is
> it just a CVS mistake?
Nessesarry for what? Each contains project files for respective version of
msvc. I use them. You could either.
Gennadiy.
___
Unsubscribe & other cha
Hi,
I finally mostly finished first long promised revision for Boost.Test.
Here is the list of major features/updates:
* Major update for documentation
I still think that docs need a lot of work. They incomplete and there are
several pages missing. Also some tutorial material needs to be exten
> Regardless, do this: make a copy of one of the status tables, hand change
> the entries for the first couple of libs to illustrate what you want,
> verify it works with a browser, and send it to me.
Maybe like this.
Gennadiy.
begin 666 Boost Compiler Status Automatic Test.htm
M/"%$3T-465!%([
"Giovanni Bajo" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hello,
>
> Boost.Test does not currently honor BOOST_DISABLE_WIN32. The attacched
patch
> fixes it. Can someone review & apply this patch?
>
> Thanks
> Giovanni Bajo
>
Ok. Applied.
BTW, Beman, You recently disabled stru
Hi,
It may be convinient fr backward references to have an anchors in compiler
status page marking beggining of each library.
What you think?
Gennadiy.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
> /// START CODE ///
> // Boost Unit Test Library:
> #include
> #include
You included test_exec_monitor.
> // Individual Components:
> // None - just a clean compile would be nice!
>
> using namespace boost::unit_test_framework;
>
> test_suite* init_unit_tes
"Vladimir Prus" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Gennadiy Rozental wrote:
>
> >> And one important point: there are only three unnamed parameters.
There's
> > a
> >> bunch of other things that can be
> OK, I understand your opinion. I'm probably misusing "you don't pay for
what
> you don't use" principle, but I find that 'options_and_argument' class is
> important. Sometimes you really don't need typed storage.
Then just use default std::string type for parameter types - you got your
string to
> Consider command line
>
>my_prog --output=/tmp/log input.cpp
>
> Here is the option with name "output" and value "/tmp/log". There's also
> argument "input.cpp".
1. Why you named namespace progrma_options it in fact you supply both.
2. How could I access argument using "high level"
variable_
> And one important point: there are only three unnamed parameters. There's
a
> bunch of other things that can be configured, and they all use *named*
> interface:
>
>desc.add_options()
>("output", "file", "output file name").default_value("/tmp/abc")
>;
The question arize: Why
"Daryle Walker" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> In a revamp of the I/O library reviewed a few months ago, I revised the
> structure of the test programs to match that given in the Boost.Test
> documentation. Is what I have alright? Someone (Beman?) mentioned the
> de
> For a command line parser, the decoupling provided by separate
> compilation seems to far outweigh the minor benefits of a header-only
> implementation. Just my opinions, of course.
We do not need to sacrify decoupling to provide both header based and
offline versions.
Gennadiy.
__
> While I don't find the interface proposed by Vladimir to be offensive,
> when you get a pile of function arguments of the same type together a
> named parameter interface *can* be a help. I don't think I'd use
> operator<<, though. If it's really about readability I'd tend to
> sacrifice some n
> I think the names "arguments" and "options" are as good as anything else.
It may be so. But I do not understand how the library use these terms.
Vladimir wrote:
> "option" is (name,value) pair
> "argument" is an command line element which is not option.
These definitions unclear to me. Could y
> There are >65 tests in that directory. Multiply that by 7 or 8 compilers,
> and it would be a huge additional testing load.
IIRC they all compile-time small tests. There should not be any problems.
Gennadiy.
___
Unsubscribe & other changes: http://
Hi,
This is not a review of the supplied library. I am not gonna discuss docs
even though they are scarce. I almost don't mention implementation/code/
testing. I just want to express my opinion on design of the library.
Following list is not ordered by importance nor any other order. It just
> Can you show me a better example? This is not a challenge. Really,
> if this ENFORCE idea is a useful one I want to understand it.
I extensively using assert-like production time enforcements to validate
user input/order of actions. I like the idea presented in article. Though I
am curently us
> typedef boost::variant GlobalParameter;
> GlobalParameter input_socket(12345);
> input_socket = "test"; // no way to prevent this
>
> // ...or if that doesn't convince you...
> GlobalParameter new_input_socket("test");
> input_socket = new_input_socket; // no way to prevent this eithe
> > 2. Could type that implements swap() method somehow follow the second
case
> > road also? For example, could you somehow deduce T* from buffer and swap
> it
> > with local copy of the argument?
>
> Yes, I can look into such optimizations. But as I noted in previous
> messages, if I can prevent
> > case MAX_WITCH:
> >visitor( Typelist[MAX_WITCH](storage) );
> >break;
> > }
> > }
>
> Your pseudo-code is misleading. There is no "MAX_WHICH" available to the
> preprocessor when MPL-sequences are given because there is no theoretical
> upper limit on the siz
> I argue that top-level const type arguments are meaningless in the context
> of variant. Given the example you provide:
>
> typedef boost::variant GlobalParameter;
>
> GlobalParameter input_socket(12345);
> input_socket = 54321; // no way to prevent this!!
How come!? It should be very easy
"Peter Dimov" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Gennadiy Rozental wrote:
> > So what I want is
> >
> > typedef boost::variant GlobalParameter;
> >
> > GlobalParameter input_socket( 12345 ); // localhost::12345
>
"Eric Friedman" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Gennadiy Rozental wrote:
> > > While I do agree O(1) is better than O(N), I would like to point out
> that
> > > it is usable only when the pseudo-variadic template interface is u
>svertka.driver.cpp(127): error in "test_svertka": test {result.begin(),
> result.end()} == {result2, ...} failed [-431600044 != -78651042]
>
> I think this message misses one thing: the position where mismatch
occured. If
> differing values are printed, it's natural to print position, too
> > > overview.) This technique is necessary to provide a general guarantee
> > > of strong exception-safety, which in turn is necessary to maintain
> > > a "never empty" invariant for variant.
> >
> > What is this invariant? And why is it that important.
>
> The invariant is quite straightforward:
> While I do agree O(1) is better than O(N), I would like to point out that
it
> is usable only when the pseudo-variadic template interface is used (i.e.,
> variant as opposed to variant).
Why? And to be absolutely clear: what do you mean by "it"?
> Also, I am still not convinced that an unrolled
> I think you misunderstand: What I'm arguing is that the "usage case" you
> propose here is itself erroneous. This is *not* an issue of whether I can
> implement the behavior. (In fact, I need to do additional work to prohibit
> it.)
>
> Let me know if you still disagree.
I disagree. Let say I wa
> If the issue concerns you this much, you might propose something along the
> lines of BOOST_NO_EXCEPTIONS.
>
> That is, you might try: "BOOST_NO_RTTI anyone?"
>
> - Eric
I did. As a user defined parameter. Terrie made a point that it should be
config parameter cause some embedded compiler indee
> > template
> > void foo( T const& )
> > {
> >
> > }
> >
> > int main()
> > {
> > boost::variant v = 5;
> >
> >// Here I want to pass const reference to integer value of variant to
> > function foo
> > // foo( get( v ) ); - type T is incorrect
> >foo( ??? );
> > }
>
> I don't s
> > mpl/contain.hpp
> > I think this is in Alexey direction: it may worth generalizing this
> > function so that if the second argument is the sequence it will
> > check that one sequence contain another.
Alexey,
What do you think about this proposition?
Gennadiy.
Implementation issues comments:
> > 2. is_static_visitable description states that this metafunction will
> > check whether the specified type is visitable by a static visitor.
> > This statement is misleading, cause you do not (and could not ) check
> > this. What you check is that type could be
> > 8. Visitation algorithm
> > In sketch presented visitation algorithm look like this:
> >
> > void foo1( which, visitor )
> > {
> > if( n = 1 )
> >visitor(...)
> >else
> > foo2( which, visitor );
> > }
> >
> > void foo2( which, visitor )
> > {
> > if( n = 2 )
> >
> > 7. Variant size
> > Unfortunately I was not able to follow exact logic behind usage of 2
> > different storages. But one thing I know:
> > sizeof(boost::variant) could not be 28.
> > >From what I view it seems that types that are used to construct
> > storage2 also used when constructed storage
> > Also I think we need free function form of value
> > extraction. In other case it would be difficult to place extract
> > in context where template parameter is deduced. And check function
> > is not that important in most cases.
>
> While I am again considering a free function, I'm not sure wh
> > 3. Copy Constructible/Assignable requirements on bounded types
> > This only need to be required if variant should have appropriate
> > feature.
>
> I disagree. As-is, every variant object requires CopyConstructible
> bounded types, as it is the only way to construct its content.
>
> Some notes
> > 5. Usage std::type_info for reflection
> > I don't think we should enforce RTTI for the variant users. We should
> > be able to postpone the decision on what kind of reflection
> > information user want till instantiation time.
>
> Please elaborate on this point. FYI, the current variant::type
> > 2. Top level const requirement on bounded types.
> > It's unreasonable. I should be able to define variant with const
> > types. It will be as usable as usual constant types are. The only
> > requirements that we may incur is that if one types is const,
> > rest should be also.
>
> It's actuall
> Hi Gennadiy, thanks for the comments. I apologize for my late response.
Hi Eric,
You got me in process of moving to new apartment, so I was offline for a
while.
I will post my comments in separate threads to simplify tracking.
Gennadiy.
___
Unsubs
> Hmmm. It works for me. I'm using BOOST_AUTO_UNIT_TEST across several of my
> source files without name collisions (after my patch). I'm also using the
GCC
> "#pragma interface" feature, which might make a difference. Pardon my
> ignorance, since I'm not very familiar with the auto unit test
imple
> >Sorry to interfere to this fine discussion, but from my standpoint
> >introduction of std::type_info into lexical_cast is a big problem. I
usually
> >compile my program with noRTTI flag effectively making any program using
new
> >lexical cast fail to link..
>
> OK, this is a new twist. Not one t
> > There's absolutely no reason I can see to make the exact exception
> > type depend on the types concerned. Just use a straightforward
> > class, something along the lines of:
> >
> > struct bad_lexical_cast : std::exception
> > {
> > bad_lexical_cast(
> >std::type
> Hum... I just had a thought. What if the output was reformatted as an html
> table? One row per library with columns for the error counts for the
> different kinds of errors. Click through to see the actual error messages.
>
> That would give us an overview we could watch as we approached release
> === //depot/devel/lib/boost/vendor/boost/test/unit_test_suite.hpp#1 -
/home/green/p4/devel/lib/boost/boost/test/unit_test_suite.hpp
> ***
> *** 267,273
> if( name_[0] == '&' )
> name_.erase( 0, 1 );
>
> ! return name_.data();
> }
>
> } // namespace d
> Just curious if anyone's doing something along these lines. A quick
> google search on boost turned up only Boost.Test, which (I think?) is
> something quite different.
This topic came up several times during last year. Nobody seems to
have reviewable results. I do have full-featured tracing/lo
> > > Notice the weird misspellings in the error messages. :)
> >
> > What do you mean?
>
> "boolle" and "intr"? :)
>
> Could this be a problem in the unit test framework?
Could be. What should it be?
I wil try to reproduce this locally after 1.30 is out.
Gennadiy
_
Thanx for the patch. I did not forget about it. Applied.
Gennadiy.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Does standard require/recomend inline in method declaration? I always
thought it ignored
class A
{
inline void foo();
};
inline void
A::foo()
{
}
Gennadiy
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.c
> BOOST_STATIC_ASSERT( is_same< list0, result >::value ); // THIS FAILS;
Use
BOOST_STATIC_ASSERT((mpl::equal< list0, result >::type::value ));
Gennadiy.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
> * [Boost.Test] Request for const fix in unit_test_suite.hpp
> Posted 12 Feb 2003. Did this ever get resolved? Gennadiy?
Fixed in second revision.
Gennadiy.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
> * The Rationale for Array-Based Streams concludes "it may have real-life
> applications." It would be a bit more satisfying if there was at least one
> example of a real-life application.
I second this. Could anybody show an example where array_stream would be
preferable to stringstream.
In othe
> It looks pretty explicit to me. If you think it can be improved,
> please propose a doc patch.
May be like this. See the patch attached.
Gennadiy.
begin 666 release_procedures.diff
[EMAIL PROTECTED](')E;&5A6-O9&4N
M:'!P(%MM97)G92!C:&%N9V5S(&9R;[EMAIL PROTECTED]')U;[EMAIL PROTECTED]&[EMAIL
> > 1. I committed it in main trunk: cvs commit abc.cpp
> > 2. I tag it with merged_to_RC_whatever tag (? this is not in a procedure
> > right now)
> > 3. I merge it to the release branch
>
> No, you got 2 and 3 reversed, and you only do the tagging after
> switching back to the trunk.
I got it no
> > P.S. Could you, please, clarify for me again what is the purpose of this
> > tag? How does it related to the fixes I made in trunk after branch is
> > created?
>
> The tag marks the last trunk revision that has been merged into the
> branch, so that when you do a merge to the branch you can alw
Hi, Beman
In examples for release procedure you are using: "merged_to_1_26_2". While
in "Release Procedures for the Release Manager" section you are mention:
"merged_to_RC_n_n_n". What is correct?
Gennadiy.
P.S. Could you, please, clarify for me again what is the purpose of this
tag? How does it
You couldn't build dlls out of Boost.Test sources on win32 platform yet. Is
there way to explicetly prohibit build of the target in Jamfile for specific
platform?
Gennadiy.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/b
Hi,
Here is my a bit late review for the variant library. In spite of several
concerns that I have, I incline to vote to ACCEPT this submission.
Design concerns I would like to be discussed and either accepted or
dismissed. Implementation issues are less important. Rest is mostly
comments.
Here
Hi,
I played today with some links validation software and set it upon
www.boost.org
Here the results for those who is interested.
http://groups.yahoo.com/group/boost/files/BrokenLinksReport.htm
I took care about Boost.Test issues.
Gennadiy.
___
U
Wait a minute!
Variant is up to review till the Sunday 2nd. And I am planning to supply my
comments.
Gennadiy.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
> In that fashion it makes sense. But the only smart_ptr that will make
> any sense is scoped_ptr. Which will only implement idea #1. As I said my
> classes offer far more.
Under smart_ptr I meant policy pased smart pointer, that supply a wide
variaty of ownership policies and allow you to writ
> > Mutex locking is a simple example of resource management idiom. All
flavors
> > of resource management are easily implemented in terms of policy based
smart
> > pointers (don't allow name to confuse you). In this particular case most
> > probably all that you need is a custom StoragePolicy. Now
> > 1. Does not Boost.Thread already have locking mechanisms
>
> The only thing boost threads offer is #1 on my list, that is "The ability
> to acquire a lock and release it when the object goes out of scope
> effectively implemented the "Monitor" concept". Implementing this idea is
> rather easy
> > 2. IMO any locking mechanisms should be implemented in terms of
smart_ptr
>
> I don't see the fundamental connection between locking and smart
> pointers.
>
> In particular, which smart_ptr are we talking about? shared_ptr [which
> may need locking internally for reference count anyway]
> or s
> If you consider a test suite a test case (which should be how it is, no?),
> then yes, that's all I'd need.
Yes. test suite is a test case.
> > 1. Boost.Thread with depend on multithreaded version of Boost.Test. 2.
> > Boost.Test will try to use minimal/basic part of Boost.Thread
> > functional
Two comments:
1. Does not Boost.Thread already have locking mechanisms
2. IMO any locking mechanisms should be implemented in terms of smart_ptr
Gennadiy.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
> > The code never promised to work in multithreaded environment, nor even
> > to be thread save. It is in my to-do list. Though recent hands in
> > several situations may require address some of these issues sooner.
>
> What?!? Where's the big, bold disclaimer about that!
It's in to-do section i
> >There still are getenv link errors in prg_exec_fail1 and prg_exec_fail2.
>
> I think I've got them fixed. Testing now.
And what is the fix?
> prg_exec_fail3.cpp is failing: Assertion(div != 0), line 32.
It what supposed to happend. Important thing is whether the test is aborted
at that momen
> I will try to address 1(without tss) 2 and 4 today.
I committed execution_monitor.cpp with changes that should address above
issues. We may try now recheck how signal handling behave on OpenBSD
Gennadiy.
___
Unsubscribe & other changes: http://lis
> I've been looking at your signal handling implementation in
>execution_monitor.cpp, and I think I've uncovered quite a few bugs, some of
>which are really quite fatal for multithreading code.
The code never promised to work in multithreaded environment, nor even to be
thread save. It is in my to
> >> bjam is reporting:
> >>
> >> don't know how to make result_report_test.pattern
> >> don't know how to make errors_handling_test.pattern
> >>
> >> So it looks like something is wrong with your Jamfile.
> >
> > I followed Dave A. recommendation and placed them in input section of
run
> >
> Someone will need to add an SCO specific platform config - I don't have
the
> access to the platform, nor do I know how to detect it - but if you can
> provide me with the information, or if you just want to go ahead and add
it
> then do so.
I will try to look into this. What is the usual proced
> Changing line 64 to:
>
> #elif defined(BOOST_HAS_SIGACTION) && !defined(__OpenBSD__)
>
> Does make the tests not hang any more.
>
> Instead it causes them to fail with core dumps, or perhaps that's a
success?
errors_handling_test supposed to cause FPE and crash in case if signal
handling is turn
> >test_fp_comparisons IS failing on all compilers for now. It shows some
> >problems with comparison alsorithm. I will take a closer look after
> >release.
>
> Maybe you could take a quick look sooner? We aren't going to branch for
> release until Monday, and the release won't happen for some t
> >However, while the header is there, CW's library doesn't actually
> >implement the debugging mechanism that this header describes. This is
> >why you're link does not work -- the code just isn't there.
>
> So Gennadiy's "temporary" fix is really the permanent fix.
There still are getenv lin
> bjam is reporting:
>
> don't know how to make result_report_test.pattern
> don't know how to make errors_handling_test.pattern
>
> So it looks like something is wrong with your Jamfile.
I followed Dave A. recommendation and placed them in input section of run
rule.
The above tests expec
I fixed config/test/Jamfile to use proper names of Boost.Test libraries.
How does this thing work in regression testing?
Gennadiy.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
> sigaction is supported by all gcc versions if the platform has it (and BSD
> does).
You right. But, then it looks like it does not work properly, cause
siglongjump causing SIGSEGV.
Maybe we do not want to use sigaction facility with gcc 2.95.3?
Could we change line 64 in execution_monitor.cpp s
> * test lib has three tests failing all compilers; at least some of these
> passed until recently.
Note that errors_handling_test and results_resport_test failures does not
lead ot any error messages.
So I would recommend to perform clean build of those two.
test_fp_comparisons IS failing on all
> > So, Let introduce one. I need something for coming release.
>
> Done: it's called BOOST_HAS_SIGACTION
>
> John.
Why it doesn't get defined for Visual Age C++ on AIX?
Gennadiy.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listi
> No, it is some sort of configuration problem.
Look on "metrowerks linking errors" thread. It about the same issue with
different undefined symbol
There was also compilation error with metrowerks. I fixed it couple hours
ago. Unfortunately I do not have direct access to this compiler so
metrower
> > Hi, everybody
> >
> > Today I committed second revision to Boost.Test library.
>
> Wow, is that a good idea one day before we branch for release?
I should have done it week ago, but was really sick. Anyway, It does not
contain anything that should break backward compartibility.
Gennadiy.
_
Hi, everybody
Today I committed second revision to Boost.Test library. I am not planning
any more code changes in this release. If I have time I will try to reflect
changes made in revision one and two in documentation (Release notes with
changes log will be present in any case). Here is approxima
Sure. Fixed.
Gennadiy.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
> If you run bjam with "-d2" option, you'll see all the command lines, which
> should be enough to find out which libraries are beeing linked.
It appears that I don't really need -d2 to get a linker line. bjam prints ot
togerther with error anyway:
mwld -search -maxerrors 5 -maxwarnings 20 -expor
1 - 100 of 147 matches
Mail list logo
