build/Jamfile.v2: line 18: s/Feaures/Features line 130: There should be a space between '!' and '<target-os>cygwin', otherwise the whole condition will never evaluate to true line 132: s/need/needs/ . Also it can be equivalently replaced with just: EXIT "error: Boost.Locale needs either iconv or ICU library to be built." ; line 200: doesn't posix backend work for BSDs other than darwin? line 283: <link>shared:<define>BOOST_LOCALE_DYN_LINK=1 should be present in usage requirements too. The same applies to <threading>multi as well. lines 275, 282: what's the reason for commenting build_options and having <conditional>@configure instead? line 288: Being a vim user myself I appreciate this, but in general tabs are not allowed in code per Boost's development policy. Users of other editors would not be happy with tabs here :) General remarks: As a Boost.Build user I would see it very beneficial when using Boost.Locale to be able to have ICU build from source with BB just like the other 3rd party libraries commonly are. For it to work Boost.Locale Jamfile can check if a project /icu is available, and if so use /icu//icu as source and skip ICU configuration checking together with options for linking to prebuilt ICU. I can prepare and propose a patch for this if that scheme is OK with you. Examples and performance benchmarks should have Jamfiles too. Gevorg
----- Original Message ----
From: Gevorg Voskanyan <v_gevorg@yahoo.com> To: boost@lists.boost.org Sent: Sat, April 16, 2011 2:18:41 PM Subject: [boost] [locale] Review: Build
build/Jamfile.v2:
line 18: s/Feaures/Features
line 130: There should be a space between '!' and '<target-os>cygwin', otherwise
the whole condition will never evaluate to true
Good point.. Why bjam does not warn?
line 132: s/need/needs/ . Also it can be equivalently replaced with just: EXIT
"error: Boost.Locale needs either iconv or ICU library to be built." ;
line 200: doesn't posix backend work for BSDs other than darwin?
No only Mac OS X (and I think Darwin) and Linux support this. It is relatively new standard POSIX 2008.
line 283: <link>shared:<define>BOOST_LOCALE_DYN_LINK=1 should be present in usage requirements too. The same applies to <threading>multi as well.
Ok
lines 275, 282: what's the reason for commenting build_options and having <conditional>@configure instead?
Old code should be removed
line 288: Being a vim user myself I appreciate this, but in general tabs are not
allowed in code per Boost's development policy. Users of other editors would not
be happy with tabs here :)
Actually it says use spaces instead of tabs and use tabs of 4... This line saves me lots of headache all over the code.
General remarks:
As a Boost.Build user I would see it very beneficial when using Boost.Locale to
be able to have ICU build from source with BB just like the other 3rd party libraries commonly are. For it to work Boost.Locale Jamfile can check if a project /icu is available, and if so use /icu//icu as source and skip ICU configuration checking together with options for linking to prebuilt ICU. I can prepare and propose a patch for this if that scheme is OK with you.
By no means. ICU is very-very complex library that has its own autotools based build system that by no means can be easily (if at all) ported to BBv2. I have enough bad times with BB building a relatively simple library Boost.Locale...
Examples and performance benchmarks should have Jamfiles too.
Good point.
Gevorg
Thanks, Artyom
Artyom wrote:
Gevorg Voskanyan wrote:
line 130: There should be a space between '!' and '<target-os>cygwin', otherwise
the whole condition will never evaluate to true
Good point.. Why bjam does not warn?
I agree it would be good if bjam gave a warning in such cases.
line 200: doesn't posix backend work for BSDs other than darwin?
No only Mac OS X (and I think Darwin) and Linux support this.
It is relatively new standard POSIX 2008.
Ok, thanks, now I see it documented in using_localization_backends.html
line 288: Being a vim user myself I appreciate this, but in general tabs are
not
allowed in code per Boost's development policy. Users of other editors would
not
be happy with tabs here :)
Actually it says use spaces instead of tabs and use tabs of 4... This line saves me lots of headache all over the code.
Yes, but still there are tab characters physically in the file, and Boost.Inspect will not like that.
General remarks:
As a Boost.Build user I would see it very beneficial when using Boost.Locale
to
be able to have ICU build from source with BB just like the other 3rd party
libraries commonly are. For it to work Boost.Locale Jamfile can check if a
project /icu is available, and if so use /icu//icu as source and skip ICU configuration checking together with options for linking to prebuilt ICU. I can prepare and propose a patch for this if that scheme is OK with you.
By no means.
Why? It would take only about 5 lines of code to support that.
ICU is very-very complex library that has its own autotools based build system that by no means can be easily (if at all) ported to BBv2.
Perhaps not easily, but I'm sure it's doable.
I have enough bad times with BB building a relatively simple library Boost.Locale...
I was not suggesting for *you* to port ICU to BB, of course not. I understand it's not a trivial task, and I remember well the struggle you went through to have Boost.Locale to build with BB. BTW, thanks for not giving up in the middle! Your persistence with bringing Boost.Locale to where it is now benefited the community. And it would not be polite, to put it mildly, had someone asked you to do that porting. So what is the problem for Boost.Locale to accommodate to a user who has ICU ported to BBv2 for his needs?
Thanks, Artyom
Regards, Gevorg
----- Original Message ----
From: Gevorg Voskanyan <v_gevorg@yahoo.com>
Actually it says use spaces instead of tabs and use tabs of 4... This line saves me lots of headache all over the code.
Yes, but still there are tab characters physically in the file, and Boost.Inspect will not like that.
Ok, I'll check, I may missed some.
As a Boost.Build user I would see it very beneficial when using Boost.Locale
to
be able to have ICU build from source with BB just like the other 3rd party
libraries commonly are. For it to work Boost.Locale Jamfile can check if
a
project /icu is available, and if so use /icu//icu as source and skip ICU
configuration checking together with options for linking to prebuilt ICU. I can prepare and propose a patch for this if that scheme is OK with you.
By no means.
Why? It would take only about 5 lines of code to support that.
What do you mean? To start native ICU build?
ICU is very-very complex library that has its own autotools based build system that by no means can be easily (if at all) ported to BBv2.
Perhaps not easily, but I'm sure it's doable.
If somebody like Vladimir Prus does it it may be doable but not with current state of BB documentation.
I have enough bad times with BB building a relatively simple library Boost.Locale...
I was not suggesting for *you* to port ICU to BB, of course not. I understand
it's not a trivial task, and I remember well the struggle you went through to
have Boost.Locale to build with BB. BTW, thanks for not giving up in the middle!
Your persistence with bringing Boost.Locale to where it is now benefited the community. And it would not be polite, to put it mildly, had someone asked you
to do that porting.
So what is the problem for Boost.Locale to accommodate to a user who has ICU ported to BBv2 for his needs?
If someone ports it would be very good. In any case there are rumors in ICU mailing lists on the fact that it may move to CMake which would make it much easier to integrate it with probably the next version of Boost's build system. Best, Artyom
Artyom wrote:
Gevorg Voskanyan wrote:
Why? It would take only about 5 lines of code to support that.
What do you mean? To start native ICU build?
To check if an /icu project is known to Boost.Build, and if so, use it.
If somebody like Vladimir Prus does it it may be doable but not with current state of BB documentation.
Even though my Boost.Build skills are certainly very far to match Vladimir's, I still managed to create BBv2 build scripts for more than a dozen 3rd party open source libraries. And yes, that with the current state of BB documentation. ICU is just the next one on my list.
If someone ports it would be very good.
We are on the same page on that.
In any case there are rumors in ICU mailing lists on the fact that it may move to CMake which would make it much easier to integrate it with probably the next version of Boost's build system.
Will not make a difference for me as my projects use BB anyway.
Best, Artyom
Regards, Gevorg
From: Gevorg Voskanyan <v_gevorg@yahoo.com>
What do you mean? To start native ICU build? [snip] If somebody like Vladimir Prus does it it may be doable but not with current state of BB documentation.
Even though my Boost.Build skills are certainly very far to match Vladimir's, I
still managed to create BBv2 build scripts for more than a dozen 3rd party open
source libraries. And yes, that with the current state of BB documentation. ICU
is just the next one on my list.
However I wouldn't be so sure that ICU would accept and maintain BBv2 build scripts. With all my respect to BBv2 and I have one, I doubt if 3rd part project would accept it even if the the Boost community there are doubts about BBv2 and plans to move to CMake (ryppl) My $0.02 Artyom
Artyom wrote:
However I wouldn't be so sure that ICU would accept and maintain BBv2 build scripts.
Honestly I didn't even plan to submit that to ICU.
With all my respect to BBv2 and I have one, I doubt if 3rd part project would accept it even if the the Boost community there are doubts about BBv2 and plans to move to CMake (ryppl)
Your scepticism is understandable. For me, if a 3rd party lib wants to accept BBv2 scripts, fine, but if it doesn't, then that's fine as well. The only concern I have here is that if I have ICU itself building with BB, I want Boost.Locale to use that instead of trying to find ICU binaries installed on the system. That is all my original point was about.
My $0.02
Thank you for sharing your perspective,
Artyom
Gevorg
participants (2)
-
Artyom -
Gevorg Voskanyan