Hi Niall - I'm trying to run the tests. I'm certain I am just doing something really silly... input is welcome! I have dropped the AFIO repo into a libs/afio directory for the super project. I ran ./b2 headers which linked in the boost/afio bits. I then go to libs/afio/test and execute "b2 release" which unfortunately results in: find: libs/afio: No such file or directory Performing configuration checks ... This is the same way I run other library tests and those are working as normal. Is there some other setup step that I'm forgetting? Thanks! michael -- Michael Caisse ciere consulting ciere.com
On 29 Aug 2015 at 23:13, Michael Caisse wrote:
I'm trying to run the tests. I'm certain I am just doing something really silly... input is welcome!
I have dropped the AFIO repo into a libs/afio directory for the super project. I ran ./b2 headers which linked in the boost/afio bits. I then go to libs/afio/test and execute "b2 release" which unfortunately results in:
find: libs/afio: No such file or directory Performing configuration checks ...
This is the same way I run other library tests and those are working as normal. Is there some other setup step that I'm forgetting?
Almost certainly you need to ask Boost.Build for C++ 11 else it ignores C++ 11 Boost libraries. See https://boostgsoc13.github.io/boost.afio/doc/html/afio/compilation.htm l Note that as AFIO is standalone capable, simply entering its directory and typing: ./standalone_alltests_gcc.sh ./test_all should "just work" if you have a Filesystem TS on your system. If not, it'll auto-configure including Boost.Filesystem. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 8/30/15 6:34 AM, Niall Douglas wrote:
Note that as AFIO is standalone capable, simply entering its directory and typing:
./standalone_alltests_gcc.sh ./test_all
should "just work" if you have a Filesystem TS on your system. If not, it'll auto-configure including Boost.Filesystem.
I realize I might be in the minority here - but I'm very much opposed to this design approach. It has been used in boost.build and probably some libraries. By design approach - I mean the practice of the library designer trying to implement what he "thinks" the user wants without advising or consulting the user so that "it just works". So in this case, I add the files to my system and run some tests. They figure out internally what other libraries to use and make things "just work". Now I recommend to some one else he use the library and he does the same thing. But in his case the system works somehow differently than it does on mine. Now we have to spend a huge amount of time trying to track down the source of the difference. Another example is I install the library and "it just works" then I move on to something else and some months later I change or remove my boost installation. compiled programs with static libraries continue to work until I rebuild one - which now works in a slightly different way. It's a huge amount effort tracking down the source and fixing this problem. moral of the story: Do not make the operation of a library implicitly dependent on some environmental feature. better alternative: a) list the requirements of the library. b) If it can depend one of several ways of doing things - list those explicitly. c) require that the user make an explicit choice. If he declines to do so, trap this condition and display error as soon as possible - do not implement code so that "it just works". d) If you can't bring yourself to do the above - require that the user explicitly specify "let system decide" or something like that. At least this will not inflict this design error on the rest of us. Robert Ramey
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Robert Ramey Sent: 30 August 2015 17:15 To: boost@lists.boost.org Subject: Re: [boost] [afio] running tests
On 8/30/15 6:34 AM, Niall Douglas wrote:
Note that as AFIO is standalone capable, simply entering its directory and typing:
./standalone_alltests_gcc.sh ./test_all
should "just work" if you have a Filesystem TS on your system. If not, it'll auto-configure including Boost.Filesystem.
I realize I might be in the minority here - but I'm very much opposed to this design approach. It has been used in boost.build and probably some libraries.
By design approach - I mean the practice of the library designer trying to implement what he "thinks" the user wants without advising or consulting the user so that "it just works".
So in this case, I add the files to my system and run some tests. They figure out internally what other libraries to use and make things "just work". Now I recommend to some one else he use the library and he does the same thing. But in his case the system works somehow differently than it does on mine. Now we have to spend a huge amount of time trying to track down the source of the difference.
Another example is I install the library and "it just works" then I move on to something else and some months later I change or remove my boost installation. compiled programs with static libraries continue to work until I rebuild one - which now works in a slightly different way. It's a huge amount effort tracking down the source and fixing this problem.
moral of the story:
Do not make the operation of a library implicitly dependent on some environmental feature.
better alternative:
a) list the requirements of the library. b) If it can depend one of several ways of doing things - list those explicitly. c) require that the user make an explicit choice. If he declines to do so, trap this condition and display error as soon as possible - do not implement code so that "it just works". d) If you can't bring yourself to do the above - require that the user explicitly specify "let system decide" or something like that. At least this will not inflict this design error on the rest of us.
+1 Boost.Build has proved this for me (and for many others judging by the stream of queries). For me, there have been more occasions when it 'just doesn't work' than when it does. Finding out why usually proves more difficult than explicitly having to specify several things in the first place. Examples of typical specification can ease that burden. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
On 30 Aug 2015 at 9:14, Robert Ramey wrote:
On 8/30/15 6:34 AM, Niall Douglas wrote:
Note that as AFIO is standalone capable, simply entering its directory and typing:
./standalone_alltests_gcc.sh ./test_all
should "just work" if you have a Filesystem TS on your system. If not, it'll auto-configure including Boost.Filesystem.
I realize I might be in the minority here - but I'm very much opposed to this design approach. It has been used in boost.build and probably some libraries.
By design approach - I mean the practice of the library designer trying to implement what he "thinks" the user wants without advising or consulting the user so that "it just works".
Every single dependency used by AFIO can be chosen via configuration macro. I believe this is unique amongst Boost libraries. It does default to certain choices if not told otherwise. Those defaults and their values and conditions are explained at https://boostgsoc13.github.io/boost.afio/doc/html/afio/compilation.htm l.
Do not make the operation of a library implicitly dependent on some environmental feature.
better alternative:
a) list the requirements of the library. b) If it can depend one of several ways of doing things - list those explicitly.
The exact requirements are listed at https://boostgsoc13.github.io/boost.afio/doc/html/afio/introduction.ht ml The configuration options and defaults are listed at https://boostgsoc13.github.io/boost.afio/doc/html/afio/compilation.htm l
c) require that the user make an explicit choice. If he declines to do so, trap this condition and display error as soon as possible - do not implement code so that "it just works".
AFIO does an #error Helpful message in exactly these situations.
d) If you can't bring yourself to do the above - require that the user explicitly specify "let system decide" or something like that. At least this will not inflict this design error on the rest of us.
The local platform auto detection only happens for standalone AFIO. If used as a Boost module, AFIO always uses Boost for everything. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
participants (4)
-
Michael Caisse -
Niall Douglas -
Paul A. Bristow -
Robert Ramey