[build] Default compiler options for a toolset
How are the default compiler options for a toolset chosen ? Is it in the .jam file for the compiler toolset and, if so, where is it specified ?
AMDG On 11/18/2013 10:56 AM, Edward Diener wrote:
How are the default compiler options for a toolset chosen ? Is it in the .jam file for the compiler toolset and, if so, where is it specified ?
Options are specified by toolset.flags in the msvc.jam (for msvc). For example: flags como-win CFLAGS <inlining>off : --no_inlining ; (I'm using como as an example, because it's simple. msvc and gcc are a bit more complex, because they are designed to handle multiple versions.) This says: for every target which is created by actions in como-win, if the value of the feature <inlining> is set to off, then append "--no_inlining" to the variable CFLAGS. Then CFLAGS is used like this: actions compile.c++ { $(CONFIG_COMMAND) -c ... -D$(DEFINES) $(CFLAGS) ... -o "$(<)" "$(>)" } In Christ, Steven Watanabe
On 11/18/2013 3:01 PM, Steven Watanabe wrote:
AMDG
On 11/18/2013 10:56 AM, Edward Diener wrote:
How are the default compiler options for a toolset chosen ? Is it in the .jam file for the compiler toolset and, if so, where is it specified ?
Options are specified by toolset.flags in the msvc.jam (for msvc). For example:
flags como-win CFLAGS <inlining>off : --no_inlining ;
(I'm using como as an example, because it's simple. msvc and gcc are a bit more complex, because they are designed to handle multiple versions.)
This says: for every target which is created by actions in como-win, if the value of the feature <inlining> is set to off, then append "--no_inlining" to the variable CFLAGS.
Then CFLAGS is used like this:
actions compile.c++ { $(CONFIG_COMMAND) -c ... -D$(DEFINES) $(CFLAGS) ... -o "$(<)" "$(>)" }
Thanks for the information, but interpreting the "action" versus the actual command line generated is difficult for me. Maybe you can help. As an example here is the action from msvc.jam: actions compile-c-c++ bind PDB_NAME { $(.CC) @"@($(<[1]:W).rsp:E="$(>[1]:W)" -Fo"$(<[1]:W)" $(PDB_CFLAG)"$(PDB_NAME)" -Yu"$(>[3]:D=)" -Fp"$(>[2]:W)" $(CC_RSPLINE))" $(.CC.FILTER) } or maybe actions compile-c-c++-pch { $(.CC) @"@($(<[1]:W).rsp:E="$(>[2]:W)" -Fo"$(<[2]:W)" -Yc"$(>[1]:D=)" $(YLOPTION)"__bjam_pch_symbol_$(>[1]:D=)" -Fp"$(<[1]:W)" $(CC_RSPLINE))" "@($(<[1]:W).cpp:E=#include $(.escaped-double-quote)$(>[1]:D=)$(.escaped-double-quote)$(.nl))" $(.CC.FILTER) } Now here is the actual command line generated from a single compile from running bjam against a preprocessor test using msvc-11.0 with the -d2 option, like 'b2 -d2 toolset=msvc-11.0'. "tuple.cpp" -Fo"some_long_path\tuple.obj" -TP /Z7 /Od /Ob0 /W4 /GR /MDd /Zc:forScope /Zc:wchar_t /wd4675 /EHs -c I am trying to discover where these options in the command line come from in the actual action. In particular I am trying to discover what in the action is generating the /EHs option.
AMDG On 11/18/2013 12:48 PM, Edward Diener wrote:
Thanks for the information, but interpreting the "action" versus the actual command line generated is difficult for me. Maybe you can help.
b2 just expands all the variables in the action to generate the command line.
As an example here is the action from msvc.jam:
actions compile-c-c++ bind PDB_NAME { $(.CC) @"@($(<[1]:W).rsp:E="$(>[1]:W)" -Fo"$(<[1]:W)" $(PDB_CFLAG)"$(PDB_NAME)" -Yu"$(>[3]:D=)" -Fp"$(>[2]:W)" $(CC_RSPLINE))" $(.CC.FILTER) }
or maybe
actions compile-c-c++-pch { $(.CC) @"@($(<[1]:W).rsp:E="$(>[2]:W)" -Fo"$(<[2]:W)" -Yc"$(>[1]:D=)" $(YLOPTION)"__bjam_pch_symbol_$(>[1]:D=)" -Fp"$(<[1]:W)" $(CC_RSPLINE))" "@($(<[1]:W).cpp:E=#include $(.escaped-double-quote)$(>[1]:D=)$(.escaped-double-quote)$(.nl))" $(.CC.FILTER) }
Now here is the actual command line generated from a single compile from running bjam against a preprocessor test using msvc-11.0 with the -d2 option, like 'b2 -d2 toolset=msvc-11.0'.
"tuple.cpp" -Fo"some_long_path\tuple.obj" -TP /Z7 /Od /Ob0 /W4 /GR /MDd /Zc:forScope /Zc:wchar_t /wd4675 /EHs -c
I am trying to discover where these options in the command line come from in the actual action. In particular I am trying to discover what in the action is generating the /EHs option.
Search for /EHs in msvc.jam: toolset.flags msvc.compile C++FLAGS <exception-handling>on/<asynch-exceptions>off/<extern-c-nothrow>off : /EHs ; C++FLAGS appears in $(CC_RSPLINE), which is set in get-rspline. rule get-rspline ( target : lang-opt ) { CC_RSPLINE on $(target) = [ on $(target) return $(lang-opt) -U$(UNDEFS) $(CFLAGS) $(C++FLAGS) $(OPTIONS) -c $(.nl)-D$(DEFINES) $(.nl)\"-I$(INCLUDES:W)\" ] ; } In Christ, Steven Watanabe
On 11/18/2013 4:56 PM, Steven Watanabe wrote:
AMDG
On 11/18/2013 12:48 PM, Edward Diener wrote:
Thanks for the information, but interpreting the "action" versus the actual command line generated is difficult for me. Maybe you can help.
b2 just expands all the variables in the action to generate the command line.
As an example here is the action from msvc.jam:
actions compile-c-c++ bind PDB_NAME { $(.CC) @"@($(<[1]:W).rsp:E="$(>[1]:W)" -Fo"$(<[1]:W)" $(PDB_CFLAG)"$(PDB_NAME)" -Yu"$(>[3]:D=)" -Fp"$(>[2]:W)" $(CC_RSPLINE))" $(.CC.FILTER) }
or maybe
actions compile-c-c++-pch { $(.CC) @"@($(<[1]:W).rsp:E="$(>[2]:W)" -Fo"$(<[2]:W)" -Yc"$(>[1]:D=)" $(YLOPTION)"__bjam_pch_symbol_$(>[1]:D=)" -Fp"$(<[1]:W)" $(CC_RSPLINE))" "@($(<[1]:W).cpp:E=#include $(.escaped-double-quote)$(>[1]:D=)$(.escaped-double-quote)$(.nl))" $(.CC.FILTER) }
Now here is the actual command line generated from a single compile from running bjam against a preprocessor test using msvc-11.0 with the -d2 option, like 'b2 -d2 toolset=msvc-11.0'.
"tuple.cpp" -Fo"some_long_path\tuple.obj" -TP /Z7 /Od /Ob0 /W4 /GR /MDd /Zc:forScope /Zc:wchar_t /wd4675 /EHs -c
I am trying to discover where these options in the command line come from in the actual action. In particular I am trying to discover what in the action is generating the /EHs option.
Search for /EHs in msvc.jam:
toolset.flags msvc.compile C++FLAGS <exception-handling>on/<asynch-exceptions>off/<extern-c-nothrow>off : /EHs ;
There are 4 lines of C++FLAGS toolset.flags msvc.compile C++FLAGS <exception-handling>on/<asynch-exceptions>off/<extern-c-nothrow>off : /EHs ; toolset.flags msvc.compile C++FLAGS <exception-handling>on/<asynch-exceptions>off/<extern-c-nothrow>on : /EHsc ; toolset.flags msvc.compile C++FLAGS <exception-handling>on/<asynch-exceptions>on/<extern-c-nothrow>off : /EHa ; toolset.flags msvc.compile C++FLAGS <exception-handling>on/<asynch-exceptions>on/<extern-c-nothrow>on : /EHac ; How is a particular one chosen ?
C++FLAGS appears in $(CC_RSPLINE), which is set in get-rspline.
rule get-rspline ( target : lang-opt ) { CC_RSPLINE on $(target) = [ on $(target) return $(lang-opt) -U$(UNDEFS) $(CFLAGS) $(C++FLAGS) $(OPTIONS) -c $(.nl)-D$(DEFINES) $(.nl)\"-I$(INCLUDES:W)\" ] ; }
AMDG On 11/18/2013 07:48 PM, Edward Diener wrote:
There are 4 lines of C++FLAGS
toolset.flags msvc.compile C++FLAGS <exception-handling>on/<asynch-exceptions>off/<extern-c-nothrow>off : /EHs ; toolset.flags msvc.compile C++FLAGS <exception-handling>on/<asynch-exceptions>off/<extern-c-nothrow>on : /EHsc ; toolset.flags msvc.compile C++FLAGS <exception-handling>on/<asynch-exceptions>on/<extern-c-nothrow>off : /EHa ; toolset.flags msvc.compile C++FLAGS <exception-handling>on/<asynch-exceptions>on/<extern-c-nothrow>on : /EHac ;
How is a particular one chosen ?
Look at the properties. If you compile with async-exceptions=on extern-c-nothrow=on, you'll get /EHac, for instance. The default for both is "off" In Christ, Steven Watanabe
On 11/18/2013 11:05 PM, Steven Watanabe wrote:
AMDG
On 11/18/2013 07:48 PM, Edward Diener wrote:
There are 4 lines of C++FLAGS
toolset.flags msvc.compile C++FLAGS <exception-handling>on/<asynch-exceptions>off/<extern-c-nothrow>off : /EHs ; toolset.flags msvc.compile C++FLAGS <exception-handling>on/<asynch-exceptions>off/<extern-c-nothrow>on : /EHsc ; toolset.flags msvc.compile C++FLAGS <exception-handling>on/<asynch-exceptions>on/<extern-c-nothrow>off : /EHa ; toolset.flags msvc.compile C++FLAGS <exception-handling>on/<asynch-exceptions>on/<extern-c-nothrow>on : /EHac ;
How is a particular one chosen ?
Look at the properties. If you compile with async-exceptions=on extern-c-nothrow=on, you'll get /EHac, for instance. The default for both is "off"
Are "defaults" harcoded somewhere or are they in some .jam file ? In the original command line I showed: "tuple.cpp" -Fo"some_long_path\tuple.obj" -TP /Z7 /Od /Ob0 /W4 /GR /MDd /Zc:forScope /Zc:wchar_t /wd4675 /EHs -c I am not setting any of those options in my user-config.jam or site-config.jam. Yet they are being generated, and maybe they are "defaults" also, but they must be coming from somewhere.
In Christ, Steven Watanabe
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
AMDG On 11/18/2013 09:06 PM, Edward Diener wrote:
On 11/18/2013 11:05 PM, Steven Watanabe wrote:
Look at the properties. If you compile with async-exceptions=on extern-c-nothrow=on, you'll get /EHac, for instance. The default for both is "off"
Are "defaults" harcoded somewhere or are they in some .jam file ?
The default value is set when the feature is declared (in builtin.jam).
In the original command line I showed:
"tuple.cpp" -Fo"some_long_path\tuple.obj" -TP /Z7 /Od /Ob0 /W4 /GR /MDd /Zc:forScope /Zc:wchar_t /wd4675 /EHs -c
-TP is used to create a precompiled header. /Z7 comes from debug-symbols=on, debug-store=object. /Od comes from optimization=off. /Ob0 comes from inlining=off, /W4 comes from warnings=all. /GR comes from rtti=on. /MDd is runtime-debugging=on, runtime-link=shared. /Zc:forScope /Zc:wchar_t /wd4675 are added unconditionally. (Note that setting variant=debug is equivalent to optimization=off, debug-symbols=on, inlining=off, runtime-debugging=on) In Christ, Steven Watanabe
On 11/19/2013 10:37 AM, Steven Watanabe wrote:
AMDG
On 11/18/2013 09:06 PM, Edward Diener wrote:
On 11/18/2013 11:05 PM, Steven Watanabe wrote:
Look at the properties. If you compile with async-exceptions=on extern-c-nothrow=on, you'll get /EHac, for instance. The default for both is "off"
Are "defaults" harcoded somewhere or are they in some .jam file ?
The default value is set when the feature is declared (in builtin.jam).
I do not understand where the default values for a C++ compile are set in builtin.jam but I will take your word for it that they are being set there somehow.
In the original command line I showed:
"tuple.cpp" -Fo"some_long_path\tuple.obj" -TP /Z7 /Od /Ob0 /W4 /GR /MDd /Zc:forScope /Zc:wchar_t /wd4675 /EHs -c
-TP is used to create a precompiled header. /Z7 comes from debug-symbols=on, debug-store=object. /Od comes from optimization=off. /Ob0 comes from inlining=off, /W4 comes from warnings=all. /GR comes from rtti=on. /MDd is runtime-debugging=on, runtime-link=shared. /Zc:forScope /Zc:wchar_t /wd4675 are added unconditionally.
I see this last being set in msvc.jam. Thanks
(Note that setting variant=debug is equivalent to optimization=off, debug-symbols=on, inlining=off, runtime-debugging=on)
OK, I understand that this will propagate, even if the Boost Build intracicies of how it works is beyond me. In a clang-win.jam toolset created by someone else and posted on the Boost Build forum, the toolset flags are inherited from msvc. This was created for clang-cl under Windows using the VC++ RTL. However there is no supported /EH(x) like option for this clang-cl compiler. How can I disable the command line from propagating this option entirely ? I do not know what clang-cl uses for the various <exception-handling>, <asynch-exceptions>, or <extern-c-nothrow> combinations, but the compiler works fine without the clang-cl equivalent, whatever it is, of VC++ /EH(x) being set. Nonetheless I want to remove this when using the clang-win.jan file since the non-support of /EH(x) in clang-cl causes repeated warning messages for each test compiled. Is there any easy way to do this in the clang-win.jam toolset so basically no /EH(x) compiler option is generated ?
On 20/11/2013 18:49, Quoth Edward Diener:
In a clang-win.jam toolset created by someone else and posted on the Boost Build forum, the toolset flags are inherited from msvc. This was created for clang-cl under Windows using the VC++ RTL. However there is no supported /EH(x) like option for this clang-cl compiler. How can I disable the command line from propagating this option entirely ? I do not know what clang-cl uses for the various <exception-handling>, <asynch-exceptions>, or <extern-c-nothrow> combinations, but the compiler works fine without the clang-cl equivalent, whatever it is, of VC++ /EH(x) being set. Nonetheless I want to remove this when using the clang-win.jan file since the non-support of /EH(x) in clang-cl causes repeated warning messages for each test compiled. Is there any easy way to do this in the clang-win.jam toolset so basically no /EH(x) compiler option is generated ?
You probably shouldn't try to remove that. Eventually the clang folks will implement exception handling "properly" for Windows (since they're aiming for compatibility), and then presumably the warning will go away. In the meantime, it's alerting you that it's not doing what MSVC would do, which might change behaviour. This is useful to know (and useful to know when that changes).
On 11/20/2013 5:12 PM, Gavin Lambert wrote:
On 20/11/2013 18:49, Quoth Edward Diener:
In a clang-win.jam toolset created by someone else and posted on the Boost Build forum, the toolset flags are inherited from msvc. This was created for clang-cl under Windows using the VC++ RTL. However there is no supported /EH(x) like option for this clang-cl compiler. How can I disable the command line from propagating this option entirely ? I do not know what clang-cl uses for the various <exception-handling>, <asynch-exceptions>, or <extern-c-nothrow> combinations, but the compiler works fine without the clang-cl equivalent, whatever it is, of VC++ /EH(x) being set. Nonetheless I want to remove this when using the clang-win.jan file since the non-support of /EH(x) in clang-cl causes repeated warning messages for each test compiled. Is there any easy way to do this in the clang-win.jam toolset so basically no /EH(x) compiler option is generated ?
You probably shouldn't try to remove that.
Eventually the clang folks will implement exception handling "properly" for Windows (since they're aiming for compatibility), and then presumably the warning will go away. In the meantime, it's alerting you that it's not doing what MSVC would do, which might change behaviour. This is useful to know (and useful to know when that changes).
I disagree. When/if clang changes the particular jam file should change appropriately, but in the current situation there is no need to have a jamfile option which is unrecognized by clang and which it reports as unrecognized for every file being compiled. It just adds to unnecessary compiler output information when using Boost Build. I am communicating to clang developers about this msvc option on their developers mailing list, so I am willing to keep up to date about this if clang does decide to support VC++'s /EH(x) options. So far the word is that they do not intend to emulate the option. I just can't figure out how to override it in the clang-win.jam file so that it does not pass an '/EH(x)' setting to clang-cl. It is Boost Build/bjam voodoo which to me is unnecessarily complicated but to Boost Build developers must be as clear as air. The major showstopper still with clang using VC++ RTL on Windows is that clang-cl does not support RTTI, meaning it always gives an error whenever a compile includes 'typeinfo' ( or 'typeinfo.h' ). But that is another problem which a bug fix should eventually solve.
AMDG On 11/20/2013 02:33 PM, Edward Diener wrote:
I just can't figure out how to override it in the clang-win.jam file so that it does not pass an '/EH(x)' setting to clang-cl. It is Boost Build/bjam voodoo which to me is unnecessarily complicated but to Boost Build developers must be as clear as air.
The system isn't designed for this. toolset.flags only allows options to be added. They can't be removed. It is possible to fix the flags manually, but it's a hack: rule compile.c++ ( targets * : sources * : properties * ) { C++FLAGS on $(targets) = [ set.difference [ on $(targets[1]) return $(C++FLAGS) ] : /EHs ] ; }
The major showstopper still with clang using VC++ RTL on Windows is that clang-cl does not support RTTI, meaning it always gives an error whenever a compile includes 'typeinfo' ( or 'typeinfo.h' ). But that is another problem which a bug fix should eventually solve.
In Christ, Steven Watanabe
On 11/20/2013 6:29 PM, Steven Watanabe wrote:
AMDG
On 11/20/2013 02:33 PM, Edward Diener wrote:
I just can't figure out how to override it in the clang-win.jam file so that it does not pass an '/EH(x)' setting to clang-cl. It is Boost Build/bjam voodoo which to me is unnecessarily complicated but to Boost Build developers must be as clear as air.
The system isn't designed for this. toolset.flags only allows options to be added. They can't be removed.
I did not think I was removing them, justy changing them to produce no compiler option. It seems a flaw in the system that one cannot specify generating no compiler option for some Boost Build option(s). What do you do when some compiler has no equivalent compiler option for a Boost Build option ?
It is possible to fix the flags manually, but it's a hack: rule compile.c++ ( targets * : sources * : properties * ) { C++FLAGS on $(targets) = [ set.difference [ on $(targets[1]) return $(C++FLAGS) ] : /EHs ] ; }
Thanks, I will give it a try.
The major showstopper still with clang using VC++ RTL on Windows is that clang-cl does not support RTTI, meaning it always gives an error whenever a compile includes 'typeinfo' ( or 'typeinfo.h' ). But that is another problem which a bug fix should eventually solve.
On 21/11/2013 12:33, Quoth Edward Diener:
I did not think I was removing them, justy changing them to produce no compiler option. It seems a flaw in the system that one cannot specify generating no compiler option for some Boost Build option(s). What do you do when some compiler has no equivalent compiler option for a Boost Build option ?
You don't specify it in the first place. The problem you're having is because your jamfile is including the msvc jamfile, but the compiler is not 100% msvc compliant. Another way you could have done it would have been to copy the msvc file and edit it to match the real capabilities of clang-win, instead of including the msvc file.
On 11/20/2013 6:59 PM, Gavin Lambert wrote:
On 21/11/2013 12:33, Quoth Edward Diener:
I did not think I was removing them, justy changing them to produce no compiler option. It seems a flaw in the system that one cannot specify generating no compiler option for some Boost Build option(s). What do you do when some compiler has no equivalent compiler option for a Boost Build option ?
You don't specify it in the first place.
The problem you're having is because your jamfile is including the msvc jamfile, but the compiler is not 100% msvc compliant.
Another way you could have done it would have been to copy the msvc file and edit it to match the real capabilities of clang-win, instead of including the msvc file.
You may be right about this but someone else created the jam file, not me. I am just trying to modify it. OTOH inheriting flags from msvc seems logically much cleaner than having to duplicate them, or even duplicate almost all of them.
On 21.11.2013 05:42, Edward Diener wrote:
On 11/20/2013 6:59 PM, Gavin Lambert wrote:
On 21/11/2013 12:33, Quoth Edward Diener:
I did not think I was removing them, justy changing them to produce no compiler option. It seems a flaw in the system that one cannot specify generating no compiler option for some Boost Build option(s). What do you do when some compiler has no equivalent compiler option for a Boost Build option ?
You don't specify it in the first place.
The problem you're having is because your jamfile is including the msvc jamfile, but the compiler is not 100% msvc compliant.
Another way you could have done it would have been to copy the msvc file and edit it to match the real capabilities of clang-win, instead of including the msvc file.
You may be right about this but someone else created the jam file, not me. I am just trying to modify it. OTOH inheriting flags from msvc seems logically much cleaner than having to duplicate them, or even duplicate almost all of them.
toolset.inherit is defined like this: rule inherit ( toolset : base ) { import $(base) ; inherit-generators $(toolset) : $(base) ; inherit-flags $(toolset) : $(base) ; inherit-rules $(toolset) : $(base) ; } You probably can do what clang-darwin does - don't call toolset.inherit, call these 3 functions directly, and then note this comment for inherit-flags: # Brings all flag definitions from the 'base' toolset into the 'toolset' # toolset. Flag definitions whose conditions make use of properties in # 'prohibited-properties' are ignored. Do not confuse property and feature, for # example <debug-symbols>on and <debug-symbols>off, so blocking one of them does # not block the other one. # # The flag conditions are not altered at all, so if a condition includes a name, # or version of a base toolset, it will not ever match the inheriting toolset. # When such flag settings must be inherited, define a rule in base toolset # module and call it as needed. # rule inherit-flags ( toolset : base : prohibited-properties * : prohibited-vars * ) So, if clang on windows does not have any particular options for exception handling you would use: toolset.inherit-flags clang-win : msvc : <exception-handling>on ; or maybe toolset.inherit-flags clang-win : msvc : <asynch-exceptions>off <asynch-exceptions>on ; Note that I can't find clang-win anywhere on trunk, but presumably after we switch to git there will be some pull request? HTH, Volodya
On 11/21/2013 12:30 AM, Vladimir Prus wrote:
On 21.11.2013 05:42, Edward Diener wrote:
On 11/20/2013 6:59 PM, Gavin Lambert wrote:
On 21/11/2013 12:33, Quoth Edward Diener:
I did not think I was removing them, justy changing them to produce no compiler option. It seems a flaw in the system that one cannot specify generating no compiler option for some Boost Build option(s). What do you do when some compiler has no equivalent compiler option for a Boost Build option ?
You don't specify it in the first place.
The problem you're having is because your jamfile is including the msvc jamfile, but the compiler is not 100% msvc compliant.
Another way you could have done it would have been to copy the msvc file and edit it to match the real capabilities of clang-win, instead of including the msvc file.
You may be right about this but someone else created the jam file, not me. I am just trying to modify it. OTOH inheriting flags from msvc seems logically much cleaner than having to duplicate them, or even duplicate almost all of them.
toolset.inherit is defined like this:
rule inherit ( toolset : base ) { import $(base) ; inherit-generators $(toolset) : $(base) ; inherit-flags $(toolset) : $(base) ; inherit-rules $(toolset) : $(base) ; }
You probably can do what clang-darwin does - don't call toolset.inherit, call these 3 functions directly, and then note this comment for inherit-flags:
# Brings all flag definitions from the 'base' toolset into the 'toolset' # toolset. Flag definitions whose conditions make use of properties in # 'prohibited-properties' are ignored. Do not confuse property and feature, for # example <debug-symbols>on and <debug-symbols>off, so blocking one of them does # not block the other one. # # The flag conditions are not altered at all, so if a condition includes a name, # or version of a base toolset, it will not ever match the inheriting toolset. # When such flag settings must be inherited, define a rule in base toolset # module and call it as needed. # rule inherit-flags ( toolset : base : prohibited-properties * : prohibited-vars * )
So, if clang on windows does not have any particular options for exception handling you would use:
toolset.inherit-flags clang-win : msvc : <exception-handling>on ;
or maybe
toolset.inherit-flags clang-win : msvc : <asynch-exceptions>off <asynch-exceptions>on ;
First of all the toolset was uploaded as an attachment to a message in the Boost Build mailing list by 'tr1gun' in reply to a message he started on that list called 'Clang windows toolset. The toolset jam file does does have these lines: toolset.inherit-generators clang-win <toolset>clang <toolset-clang:platform>win : msvc ; toolset.inherit-flags clang-win : msvc : <debug-symbols>on/<debug-store>object : YLOPTION ; toolset.inherit-rules clang-win : msvc ; The issue is that clang does not support any /EH(x) option of msvc and I am trying to change it so that option is not generated when using the clang-win toolset is used to compile ( clang-cl ). Luckily the "hack" which Steve Watanabe showed me in reply to another message on this thread does work to eliminate any /EH(x) option.
Note that I can't find clang-win anywhere on trunk, but presumably after we switch to git there will be some pull request?
It is not on trunk or anywhere, except as an attachment in the aforementioned Boost Build thread mentioned above. I made a previous appeal on the Boost Build mailing list for a Boost Build implementation of clang on Windows using VC++ but no one responded. Then 'tr1gun' responded with his implementation and I have been using it locally to test out clang on Windows using VC++.
On 21.11.2013 10:16, Edward Diener wrote:
On 11/21/2013 12:30 AM, Vladimir Prus wrote:
On 21.11.2013 05:42, Edward Diener wrote:
On 11/20/2013 6:59 PM, Gavin Lambert wrote:
On 21/11/2013 12:33, Quoth Edward Diener:
I did not think I was removing them, justy changing them to produce no compiler option. It seems a flaw in the system that one cannot specify generating no compiler option for some Boost Build option(s). What do you do when some compiler has no equivalent compiler option for a Boost Build option ?
You don't specify it in the first place.
The problem you're having is because your jamfile is including the msvc jamfile, but the compiler is not 100% msvc compliant.
Another way you could have done it would have been to copy the msvc file and edit it to match the real capabilities of clang-win, instead of including the msvc file.
You may be right about this but someone else created the jam file, not me. I am just trying to modify it. OTOH inheriting flags from msvc seems logically much cleaner than having to duplicate them, or even duplicate almost all of them.
toolset.inherit is defined like this:
rule inherit ( toolset : base ) { import $(base) ; inherit-generators $(toolset) : $(base) ; inherit-flags $(toolset) : $(base) ; inherit-rules $(toolset) : $(base) ; }
You probably can do what clang-darwin does - don't call toolset.inherit, call these 3 functions directly, and then note this comment for inherit-flags:
# Brings all flag definitions from the 'base' toolset into the 'toolset' # toolset. Flag definitions whose conditions make use of properties in # 'prohibited-properties' are ignored. Do not confuse property and feature, for # example <debug-symbols>on and <debug-symbols>off, so blocking one of them does # not block the other one. # # The flag conditions are not altered at all, so if a condition includes a name, # or version of a base toolset, it will not ever match the inheriting toolset. # When such flag settings must be inherited, define a rule in base toolset # module and call it as needed. # rule inherit-flags ( toolset : base : prohibited-properties * : prohibited-vars * )
So, if clang on windows does not have any particular options for exception handling you would use:
toolset.inherit-flags clang-win : msvc : <exception-handling>on ;
or maybe
toolset.inherit-flags clang-win : msvc : <asynch-exceptions>off <asynch-exceptions>on ;
First of all the toolset was uploaded as an attachment to a message in the Boost Build mailing list by 'tr1gun' in reply to a message he started on that list called 'Clang windows toolset.
The toolset jam file does does have these lines:
toolset.inherit-generators clang-win <toolset>clang <toolset-clang:platform>win : msvc ; toolset.inherit-flags clang-win : msvc : <debug-symbols>on/<debug-store>object : YLOPTION ; toolset.inherit-rules clang-win : msvc ;
The issue is that clang does not support any /EH(x) option of msvc and I am trying to change it so that option is not generated when using the clang-win toolset is used to compile ( clang-cl ).
So what if you add <asynch-exceptions>off <asynch-exceptions>on to inherit-flags invocation above?
Luckily the "hack" which Steve Watanabe showed me in reply to another message on this thread does work to eliminate any /EH(x) option.
Note that I can't find clang-win anywhere on trunk, but presumably after we switch to git there will be some pull request?
It is not on trunk or anywhere, except as an attachment in the aforementioned Boost Build thread mentioned above. I made a previous appeal on the Boost Build mailing list for a Boost Build implementation of clang on Windows using VC++ but no one responded. Then 'tr1gun' responded with his implementation and I have been using it locally to test out clang on Windows using VC++.
It seems normal process to me, really - except that eventually, somebody should propose this for inclusion, hopefully when clang on Windows is part of regression testing matrix. - Volodya
On 11/21/2013 2:42 AM, Vladimir Prus wrote:
On 21.11.2013 10:16, Edward Diener wrote:
On 11/21/2013 12:30 AM, Vladimir Prus wrote:
On 21.11.2013 05:42, Edward Diener wrote:
On 11/20/2013 6:59 PM, Gavin Lambert wrote:
On 21/11/2013 12:33, Quoth Edward Diener:
I did not think I was removing them, justy changing them to produce no compiler option. It seems a flaw in the system that one cannot specify generating no compiler option for some Boost Build option(s). What do you do when some compiler has no equivalent compiler option for a Boost Build option ?
You don't specify it in the first place.
The problem you're having is because your jamfile is including the msvc jamfile, but the compiler is not 100% msvc compliant.
Another way you could have done it would have been to copy the msvc file and edit it to match the real capabilities of clang-win, instead of including the msvc file.
You may be right about this but someone else created the jam file, not me. I am just trying to modify it. OTOH inheriting flags from msvc seems logically much cleaner than having to duplicate them, or even duplicate almost all of them.
toolset.inherit is defined like this:
rule inherit ( toolset : base ) { import $(base) ; inherit-generators $(toolset) : $(base) ; inherit-flags $(toolset) : $(base) ; inherit-rules $(toolset) : $(base) ; }
You probably can do what clang-darwin does - don't call toolset.inherit, call these 3 functions directly, and then note this comment for inherit-flags:
# Brings all flag definitions from the 'base' toolset into the 'toolset' # toolset. Flag definitions whose conditions make use of properties in # 'prohibited-properties' are ignored. Do not confuse property and feature, for # example <debug-symbols>on and <debug-symbols>off, so blocking one of them does # not block the other one. # # The flag conditions are not altered at all, so if a condition includes a name, # or version of a base toolset, it will not ever match the inheriting toolset. # When such flag settings must be inherited, define a rule in base toolset # module and call it as needed. # rule inherit-flags ( toolset : base : prohibited-properties * : prohibited-vars * )
So, if clang on windows does not have any particular options for exception handling you would use:
toolset.inherit-flags clang-win : msvc : <exception-handling>on ;
or maybe
toolset.inherit-flags clang-win : msvc : <asynch-exceptions>off <asynch-exceptions>on ;
First of all the toolset was uploaded as an attachment to a message in the Boost Build mailing list by 'tr1gun' in reply to a message he started on that list called 'Clang windows toolset.
The toolset jam file does does have these lines:
toolset.inherit-generators clang-win <toolset>clang <toolset-clang:platform>win : msvc ; toolset.inherit-flags clang-win : msvc : <debug-symbols>on/<debug-store>object : YLOPTION ; toolset.inherit-rules clang-win : msvc ;
The issue is that clang does not support any /EH(x) option of msvc and I am trying to change it so that option is not generated when using the clang-win toolset is used to compile ( clang-cl ).
So what if you add
<asynch-exceptions>off <asynch-exceptions>on
to inherit-flags invocation above?
That works ! Thanks for the solution to the problem of eliminating /EH(x) from the clang using VC++ RTL tests.
On 12/5/2013 2:32 AM, Edward Diener wrote:
On 11/21/2013 2:42 AM, Vladimir Prus wrote:
On 21.11.2013 10:16, Edward Diener wrote:
On 11/21/2013 12:30 AM, Vladimir Prus wrote:
On 21.11.2013 05:42, Edward Diener wrote:
On 11/20/2013 6:59 PM, Gavin Lambert wrote:
On 21/11/2013 12:33, Quoth Edward Diener: > I did not think I was removing them, justy changing them to > produce no > compiler option. It seems a flaw in the system that one cannot > specify > generating no compiler option for some Boost Build option(s). > What do > you do when some compiler has no equivalent compiler option for a > Boost > Build option ?
You don't specify it in the first place.
The problem you're having is because your jamfile is including the msvc jamfile, but the compiler is not 100% msvc compliant.
Another way you could have done it would have been to copy the msvc file and edit it to match the real capabilities of clang-win, instead of including the msvc file.
You may be right about this but someone else created the jam file, not me. I am just trying to modify it. OTOH inheriting flags from msvc seems logically much cleaner than having to duplicate them, or even duplicate almost all of them.
toolset.inherit is defined like this:
rule inherit ( toolset : base ) { import $(base) ; inherit-generators $(toolset) : $(base) ; inherit-flags $(toolset) : $(base) ; inherit-rules $(toolset) : $(base) ; }
You probably can do what clang-darwin does - don't call toolset.inherit, call these 3 functions directly, and then note this comment for inherit-flags:
# Brings all flag definitions from the 'base' toolset into the 'toolset' # toolset. Flag definitions whose conditions make use of properties in # 'prohibited-properties' are ignored. Do not confuse property and feature, for # example <debug-symbols>on and <debug-symbols>off, so blocking one of them does # not block the other one. # # The flag conditions are not altered at all, so if a condition includes a name, # or version of a base toolset, it will not ever match the inheriting toolset. # When such flag settings must be inherited, define a rule in base toolset # module and call it as needed. # rule inherit-flags ( toolset : base : prohibited-properties * : prohibited-vars * )
So, if clang on windows does not have any particular options for exception handling you would use:
toolset.inherit-flags clang-win : msvc : <exception-handling>on ;
or maybe
toolset.inherit-flags clang-win : msvc : <asynch-exceptions>off <asynch-exceptions>on ;
First of all the toolset was uploaded as an attachment to a message in the Boost Build mailing list by 'tr1gun' in reply to a message he started on that list called 'Clang windows toolset.
The toolset jam file does does have these lines:
toolset.inherit-generators clang-win <toolset>clang <toolset-clang:platform>win : msvc ; toolset.inherit-flags clang-win : msvc : <debug-symbols>on/<debug-store>object : YLOPTION ; toolset.inherit-rules clang-win : msvc ;
The issue is that clang does not support any /EH(x) option of msvc and I am trying to change it so that option is not generated when using the clang-win toolset is used to compile ( clang-cl ).
So what if you add
<asynch-exceptions>off <asynch-exceptions>on
to inherit-flags invocation above?
That works ! Thanks for the solution to the problem of eliminating /EH(x) from the clang using VC++ RTL tests.
I spoke soo soon. Even with the above added to the inherit-flags invocation the command line still generates the /EHs option.
On 09.12.2013 01:03, Edward Diener wrote:
On 12/5/2013 2:32 AM, Edward Diener wrote:
On 11/21/2013 2:42 AM, Vladimir Prus wrote:
On 21.11.2013 10:16, Edward Diener wrote:
On 11/21/2013 12:30 AM, Vladimir Prus wrote:
On 21.11.2013 05:42, Edward Diener wrote:
On 11/20/2013 6:59 PM, Gavin Lambert wrote: > On 21/11/2013 12:33, Quoth Edward Diener: >> I did not think I was removing them, justy changing them to >> produce no >> compiler option. It seems a flaw in the system that one cannot >> specify >> generating no compiler option for some Boost Build option(s). >> What do >> you do when some compiler has no equivalent compiler option for a >> Boost >> Build option ? > > You don't specify it in the first place. > > The problem you're having is because your jamfile is including the > msvc > jamfile, but the compiler is not 100% msvc compliant. > > Another way you could have done it would have been to copy the msvc > file > and edit it to match the real capabilities of clang-win, instead of > including the msvc file.
You may be right about this but someone else created the jam file, not me. I am just trying to modify it. OTOH inheriting flags from msvc seems logically much cleaner than having to duplicate them, or even duplicate almost all of them.
toolset.inherit is defined like this:
rule inherit ( toolset : base ) { import $(base) ; inherit-generators $(toolset) : $(base) ; inherit-flags $(toolset) : $(base) ; inherit-rules $(toolset) : $(base) ; }
You probably can do what clang-darwin does - don't call toolset.inherit, call these 3 functions directly, and then note this comment for inherit-flags:
# Brings all flag definitions from the 'base' toolset into the 'toolset' # toolset. Flag definitions whose conditions make use of properties in # 'prohibited-properties' are ignored. Do not confuse property and feature, for # example <debug-symbols>on and <debug-symbols>off, so blocking one of them does # not block the other one. # # The flag conditions are not altered at all, so if a condition includes a name, # or version of a base toolset, it will not ever match the inheriting toolset. # When such flag settings must be inherited, define a rule in base toolset # module and call it as needed. # rule inherit-flags ( toolset : base : prohibited-properties * : prohibited-vars * )
So, if clang on windows does not have any particular options for exception handling you would use:
toolset.inherit-flags clang-win : msvc : <exception-handling>on ;
or maybe
toolset.inherit-flags clang-win : msvc : <asynch-exceptions>off <asynch-exceptions>on ;
First of all the toolset was uploaded as an attachment to a message in the Boost Build mailing list by 'tr1gun' in reply to a message he started on that list called 'Clang windows toolset.
The toolset jam file does does have these lines:
toolset.inherit-generators clang-win <toolset>clang <toolset-clang:platform>win : msvc ; toolset.inherit-flags clang-win : msvc : <debug-symbols>on/<debug-store>object : YLOPTION ; toolset.inherit-rules clang-win : msvc ;
The issue is that clang does not support any /EH(x) option of msvc and I am trying to change it so that option is not generated when using the clang-win toolset is used to compile ( clang-cl ).
So what if you add
<asynch-exceptions>off <asynch-exceptions>on
to inherit-flags invocation above?
That works ! Thanks for the solution to the problem of eliminating /EH(x) from the clang using VC++ RTL tests.
I spoke soo soon. Even with the above added to the inherit-flags invocation the command line still generates the /EHs option.
Can you fork the 'boostorg/build' repository on github, and put your changes to the develop branch thereof and then point to the commit? Otherwise it's hard to keep track of what changes are applied to which initial file. Thanks,
On 12/8/2013 11:16 PM, Vladimir Prus wrote:
On 09.12.2013 01:03, Edward Diener wrote:
On 12/5/2013 2:32 AM, Edward Diener wrote:
On 11/21/2013 2:42 AM, Vladimir Prus wrote:
On 21.11.2013 10:16, Edward Diener wrote:
On 11/21/2013 12:30 AM, Vladimir Prus wrote:
On 21.11.2013 05:42, Edward Diener wrote: > On 11/20/2013 6:59 PM, Gavin Lambert wrote: >> On 21/11/2013 12:33, Quoth Edward Diener: >>> I did not think I was removing them, justy changing them to >>> produce no >>> compiler option. It seems a flaw in the system that one cannot >>> specify >>> generating no compiler option for some Boost Build option(s). >>> What do >>> you do when some compiler has no equivalent compiler option for a >>> Boost >>> Build option ? >> >> You don't specify it in the first place. >> >> The problem you're having is because your jamfile is including the >> msvc >> jamfile, but the compiler is not 100% msvc compliant. >> >> Another way you could have done it would have been to copy the msvc >> file >> and edit it to match the real capabilities of clang-win, instead of >> including the msvc file. > > You may be right about this but someone else created the jam > file, not > me. I am just trying to modify it. OTOH inheriting flags from msvc > seems logically much cleaner than having to duplicate them, or even > duplicate almost all of them.
toolset.inherit is defined like this:
rule inherit ( toolset : base ) { import $(base) ; inherit-generators $(toolset) : $(base) ; inherit-flags $(toolset) : $(base) ; inherit-rules $(toolset) : $(base) ; }
You probably can do what clang-darwin does - don't call toolset.inherit, call these 3 functions directly, and then note this comment for inherit-flags:
# Brings all flag definitions from the 'base' toolset into the 'toolset' # toolset. Flag definitions whose conditions make use of properties in # 'prohibited-properties' are ignored. Do not confuse property and feature, for # example <debug-symbols>on and <debug-symbols>off, so blocking one of them does # not block the other one. # # The flag conditions are not altered at all, so if a condition includes a name, # or version of a base toolset, it will not ever match the inheriting toolset. # When such flag settings must be inherited, define a rule in base toolset # module and call it as needed. # rule inherit-flags ( toolset : base : prohibited-properties * : prohibited-vars * )
So, if clang on windows does not have any particular options for exception handling you would use:
toolset.inherit-flags clang-win : msvc : <exception-handling>on ;
or maybe
toolset.inherit-flags clang-win : msvc : <asynch-exceptions>off <asynch-exceptions>on ;
First of all the toolset was uploaded as an attachment to a message in the Boost Build mailing list by 'tr1gun' in reply to a message he started on that list called 'Clang windows toolset.
The toolset jam file does does have these lines:
toolset.inherit-generators clang-win <toolset>clang <toolset-clang:platform>win : msvc ; toolset.inherit-flags clang-win : msvc : <debug-symbols>on/<debug-store>object : YLOPTION ; toolset.inherit-rules clang-win : msvc ;
The issue is that clang does not support any /EH(x) option of msvc and I am trying to change it so that option is not generated when using the clang-win toolset is used to compile ( clang-cl ).
So what if you add
<asynch-exceptions>off <asynch-exceptions>on
to inherit-flags invocation above?
That works ! Thanks for the solution to the problem of eliminating /EH(x) from the clang using VC++ RTL tests.
I spoke soo soon. Even with the above added to the inherit-flags invocation the command line still generates the /EHs option.
Can you fork the 'boostorg/build' repository on github, and put your changes to the develop branch thereof and then point to the commit? Otherwise it's hard to keep track of what changes are applied to which initial file.
You can clone the repository with my changes at 'develop' from https://github.com/eldiener/build.git. You will need to build clang on Window using VC++ RTL in order to test out clang using clang-cl. My user-config.jam line for clang is: using clang : 3.4 : C:/Programming/VersionControl/bclang/bin/Release/clang-cl.exe : <cxxflags>"/D_HAS_EXCEPTIONS=0 /D_STATIC_CPPLIB /GR-" <compatibility>vc11 ; You can build the latest clang-cl etc. by following the instructions at http://clang.llvm.org/get_started.html and using Visual Studio to build everything. You will also need the free Visual Stusio Express to build everything. Using clang-cl still has compiler problems when typeinfo is included. I have already informed the clang developers of this via a bug report. But it would still be very nice if we could have an official toolset for it in Boost Build. More info about running clang-cl is at http://clang.llvm.org/docs/UsersManual.html#clang-cl .
On Mon, Dec 9, 2013 at 7:07 PM, Edward Diener <eldiener@tropicsoft.com>wrote:
You can clone the repository with my changes at 'develop' from https://github.com/eldiener/build.git. You will need to build clang on Window using VC++ RTL in order to test out clang using clang-cl. My user-config.jam line for clang is:
using clang : 3.4 : C:/Programming/VersionControl/ bclang/bin/Release/clang-cl.exe : <cxxflags>"/D_HAS_EXCEPTIONS=0 /D_STATIC_CPPLIB /GR-" <compatibility>vc11 ;
You can build the latest clang-cl etc. by following the instructions at http://clang.llvm.org/get_started.html and using Visual Studio to build everything. You will also need the free Visual Stusio Express to build everything.
Using clang-cl still has compiler problems when typeinfo is included. I have already informed the clang developers of this via a bug report. But it would still be very nice if we could have an official toolset for it in Boost Build. More info about running clang-cl is at http://clang.llvm.org/docs/UsersManual.html#clang-cl .
Won't the regular snapshots suffice? Last I checked it included clang-cl.exe etc. http://llvm.org/builds/ Btw, do you know off-hand what bug# is tracking the typeinfo problems? (If not it's np, I'm sure it's not hard to find with the right search parameters.) Thanks.
On 12/10/2013 1:40 AM, Joshua Boyce wrote:
On Mon, Dec 9, 2013 at 7:07 PM, Edward Diener <eldiener@tropicsoft.com>wrote:
You can clone the repository with my changes at 'develop' from https://github.com/eldiener/build.git. You will need to build clang on Window using VC++ RTL in order to test out clang using clang-cl. My user-config.jam line for clang is:
using clang : 3.4 : C:/Programming/VersionControl/ bclang/bin/Release/clang-cl.exe : <cxxflags>"/D_HAS_EXCEPTIONS=0 /D_STATIC_CPPLIB /GR-" <compatibility>vc11 ;
You can build the latest clang-cl etc. by following the instructions at http://clang.llvm.org/get_started.html and using Visual Studio to build everything. You will also need the free Visual Stusio Express to build everything.
Using clang-cl still has compiler problems when typeinfo is included. I have already informed the clang developers of this via a bug report. But it would still be very nice if we could have an official toolset for it in Boost Build. More info about running clang-cl is at http://clang.llvm.org/docs/UsersManual.html#clang-cl .
Won't the regular snapshots suffice? Last I checked it included clang-cl.exe etc.
Quite possibly. I have never used the snapshots but I just get the latest from the llvm/clang repositories and build.
Btw, do you know off-hand what bug# is tracking the typeinfo problems? (If not it's np, I'm sure it's not hard to find with the right search parameters.)
17403 18179
On 11/20/2013 6:29 PM, Steven Watanabe wrote:
AMDG
On 11/20/2013 02:33 PM, Edward Diener wrote:
I just can't figure out how to override it in the clang-win.jam file so that it does not pass an '/EH(x)' setting to clang-cl. It is Boost Build/bjam voodoo which to me is unnecessarily complicated but to Boost Build developers must be as clear as air.
The system isn't designed for this. toolset.flags only allows options to be added. They can't be removed.
It is possible to fix the flags manually, but it's a hack: rule compile.c++ ( targets * : sources * : properties * ) { C++FLAGS on $(targets) = [ set.difference [ on $(targets[1]) return $(C++FLAGS) ] : /EHs ] ; }
Bravo ! Your "hack" above works correctly and the /EHs option has been eliminated. The clang output now looks much better. I had to do an 'import set ;' but it works fine.
The major showstopper still with clang using VC++ RTL on Windows is that clang-cl does not support RTTI, meaning it always gives an error whenever a compile includes 'typeinfo' ( or 'typeinfo.h' ). But that is another problem which a bug fix should eventually solve.
On 11/20/2013 6:29 PM, Steven Watanabe wrote:
AMDG
On 11/20/2013 02:33 PM, Edward Diener wrote:
I just can't figure out how to override it in the clang-win.jam file so that it does not pass an '/EH(x)' setting to clang-cl. It is Boost Build/bjam voodoo which to me is unnecessarily complicated but to Boost Build developers must be as clear as air.
The system isn't designed for this. toolset.flags only allows options to be added. They can't be removed.
It is possible to fix the flags manually, but it's a hack: rule compile.c++ ( targets * : sources * : properties * ) { C++FLAGS on $(targets) = [ set.difference [ on $(targets[1]) return $(C++FLAGS) ] : /EHs ] ; }
I had successfully added the above to my local clang-win.jam file. While this works when compiling with clang to remove the /EHs option, when I have a 'run' action, as opposed to a 'compile' or 'compile-fail' action, no compile takes place at all but the 'run' action attempts to do a link without a compile, and of course it fails because the object file it is looking for does not exist. Is there something else I need to add to my clang-win.jam file so that the compile is done before the link when a 'run' action is encountered ? Without the rule above being added to my clang-win.jam file a 'run' action does attempt a compile before it does the link, but of course the compile now uses the obsolete for clang /EHs compile flag.
On Wed, Nov 20, 2013 at 05:33:33PM -0500, Edward Diener wrote:
I disagree. When/if clang changes the particular jam file should change appropriately.
What about people that must, want to, or need to use a Boost version released with the proposed /EH muting in effect together with a future clang-cl compiler that actually implements /EH. Not everyone updates libraries and compilers at the same pace, particularly in commercial settings or when targetting multiple compilers. -- Lars Viklund | zao@acc.umu.se
On 11/21/2013 11:07 AM, Lars Viklund wrote:
On Wed, Nov 20, 2013 at 05:33:33PM -0500, Edward Diener wrote:
I disagree. When/if clang changes the particular jam file should change appropriately.
What about people that must, want to, or need to use a Boost version released with the proposed /EH muting in effect together with a future clang-cl compiler that actually implements /EH.
Why in the world would I add a compiler option to a compiler which does not support it just in case that compiler might support that compiler option in the future ?
On Thu, Nov 21, 2013 at 03:28:26PM -0500, Edward Diener wrote:
On 11/21/2013 11:07 AM, Lars Viklund wrote:
On Wed, Nov 20, 2013 at 05:33:33PM -0500, Edward Diener wrote:
I disagree. When/if clang changes the particular jam file should change appropriately.
What about people that must, want to, or need to use a Boost version released with the proposed /EH muting in effect together with a future clang-cl compiler that actually implements /EH.
Why in the world would I add a compiler option to a compiler which does not support it just in case that compiler might support that compiler option in the future ?
From the sounds of it, this seems to be more about actively removing things that are already in place.
And as for "might", I'd bet three pinecones on that it is actually "will", unless some patent or other fundamental stupidity _prevents_ proper EH/RTTI in future Clang. To be honest, you're weighing some minor warning spam from the compiler against forever making a release unusable with future versions of that compiler. Sadly I don't get to make the choice, but I sure will say my opinion on things that look intrinsically odd. (I'd like my bikeshed purple, thank you.) -- Lars Viklund | zao@acc.umu.se
On 11/21/2013 3:43 PM, Lars Viklund wrote:
On Thu, Nov 21, 2013 at 03:28:26PM -0500, Edward Diener wrote:
On 11/21/2013 11:07 AM, Lars Viklund wrote:
On Wed, Nov 20, 2013 at 05:33:33PM -0500, Edward Diener wrote:
I disagree. When/if clang changes the particular jam file should change appropriately.
What about people that must, want to, or need to use a Boost version released with the proposed /EH muting in effect together with a future clang-cl compiler that actually implements /EH.
Why in the world would I add a compiler option to a compiler which does not support it just in case that compiler might support that compiler option in the future ?
From the sounds of it, this seems to be more about actively removing things that are already in place.
And as for "might", I'd bet three pinecones on that it is actually "will", unless some patent or other fundamental stupidity _prevents_ proper EH/RTTI in future Clang.
To be honest, you're weighing some minor warning spam from the compiler against forever making a release unusable with future versions of that compiler.
Sadly I don't get to make the choice, but I sure will say my opinion on things that look intrinsically odd.
(I'd like my bikeshed purple, thank you.)
Please go to the e-mail called "Clang windows toolset" on the Boost Build mailing list and download the attached files there by 'tr1gun' and do whatever you wish with them. I am just using those jam files locally in order to test clang-cl on Windows using Boost Build for myself. You can do the same also if you desire. Given that the Boost Build mavens had no interest, and may still have no interest, in a toolset for clang-cl, I am just thankful to be using the product of another person's efforts to achieve my goal of testing clang-cl with Boost and fixing problems in Boost that will make it easier for Boost end-users to use clang-cl if Boost Build ever officially supports it. I do not know who 'tr1gun' is but am thankful for his efforts. What I do locally in order to correctly test clang-cl with Boost Build is my own business, while whatever fixes I make to Boost for clang-cl in various Boost libraries is Boost's business. But I have made no effort to promote the jam files created by 'trgun' in any official way as a part of Boost or Boost Build.
On Fri, Nov 22, 2013 at 12:40 PM, Edward Diener <eldiener@tropicsoft.com>wrote:
Please go to the e-mail called "Clang windows toolset" on the Boost Build mailing list and download the attached files there by 'tr1gun' and do whatever you wish with them. I am just using those jam files locally in order to test clang-cl on Windows using Boost Build for myself. You can do the same also if you desire.
Given that the Boost Build mavens had no interest, and may still have no interest, in a toolset for clang-cl, I am just thankful to be using the product of another person's efforts to achieve my goal of testing clang-cl with Boost and fixing problems in Boost that will make it easier for Boost end-users to use clang-cl if Boost Build ever officially supports it. I do not know who 'tr1gun' is but am thankful for his efforts. What I do locally in order to correctly test clang-cl with Boost Build is my own business, while whatever fixes I make to Boost for clang-cl in various Boost libraries is Boost's business. But I have made no effort to promote the jam files created by 'trgun' in any official way as a part of Boost or Boost Build.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost
Any chance you could share the changes you make to the toolset files for those of us who are also interested? TIA.
On 11/21/2013 9:35 PM, Joshua Boyce wrote:
On Fri, Nov 22, 2013 at 12:40 PM, Edward Diener <eldiener@tropicsoft.com>wrote:
Please go to the e-mail called "Clang windows toolset" on the Boost Build mailing list and download the attached files there by 'tr1gun' and do whatever you wish with them. I am just using those jam files locally in order to test clang-cl on Windows using Boost Build for myself. You can do the same also if you desire.
Given that the Boost Build mavens had no interest, and may still have no interest, in a toolset for clang-cl, I am just thankful to be using the product of another person's efforts to achieve my goal of testing clang-cl with Boost and fixing problems in Boost that will make it easier for Boost end-users to use clang-cl if Boost Build ever officially supports it. I do not know who 'tr1gun' is but am thankful for his efforts. What I do locally in order to correctly test clang-cl with Boost Build is my own business, while whatever fixes I make to Boost for clang-cl in various Boost libraries is Boost's business. But I have made no effort to promote the jam files created by 'trgun' in any official way as a part of Boost or Boost Build.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost
Any chance you could share the changes you make to the toolset files for those of us who are also interested?
The only changed I made followed the "hackery" provided by Steve Watanabe to get rid of the /EHs option. Other than that the files are exactly those that were attached to the e-mail mentioned above.
On Thu, Nov 21, 2013 at 08:40:08PM -0500, Edward Diener wrote:
Please go to the e-mail called "Clang windows toolset" on the Boost Build mailing list and download the attached files there by 'tr1gun' and do whatever you wish with them. I am just using those jam files locally in order to test clang-cl on Windows using Boost Build for myself. You can do the same also if you desire.
I was of the impression that this was something you put some effort into to try to get into Boost proper. If it's just your idle musings about something that no-one will touch and you have to follow a ton of posts and patch chains for, do whatever you want.
Given that the Boost Build mavens had no interest, and may still have no interest, in a toolset for clang-cl, I am just thankful to be using the product of another person's efforts to achieve my goal of testing clang-cl with Boost and fixing problems in Boost that will make it easier for Boost end-users to use clang-cl if Boost Build ever officially supports it. I do not know who 'tr1gun' is but am thankful for his efforts. What I do locally in order to correctly test clang-cl with Boost Build is my own business, while whatever fixes I make to Boost for clang-cl in various Boost libraries is Boost's business. But I have made no effort to promote the jam files created by 'trgun' in any official way as a part of Boost or Boost Build.
The way you put it forth made it sound very much like an rather official and serious effort to formalize something due for inclusion soon, if not already in trunk. I'm sorry for misinterpreting this, but I still believe my opinion holds for any future inclusion of such functionality in Boost, no matter what compiler and feature it happens to be about. Let's not forget, not everyone reads everything on the list, mark-thread-as-read is my coping mechanism for high-volume lists like this and cfe-dev@. -- Lars Viklund | zao@acc.umu.se
On 11/19/2013 10:37 AM, Steven Watanabe wrote:
AMDG
On 11/18/2013 09:06 PM, Edward Diener wrote:
On 11/18/2013 11:05 PM, Steven Watanabe wrote:
Look at the properties. If you compile with async-exceptions=on extern-c-nothrow=on, you'll get /EHac, for instance. The default for both is "off"
Are "defaults" harcoded somewhere or are they in some .jam file ?
The default value is set when the feature is declared (in builtin.jam).
In the original command line I showed:
"tuple.cpp" -Fo"some_long_path\tuple.obj" -TP /Z7 /Od /Ob0 /W4 /GR /MDd /Zc:forScope /Zc:wchar_t /wd4675 /EHs -c
-TP is used to create a precompiled header. /Z7 comes from debug-symbols=on, debug-store=object. /Od comes from optimization=off. /Ob0 comes from inlining=off, /W4 comes from warnings=all. /GR comes from rtti=on. /MDd is runtime-debugging=on, runtime-link=shared. /Zc:forScope /Zc:wchar_t /wd4675 are added unconditionally.
(Note that setting variant=debug is equivalent to optimization=off, debug-symbols=on, inlining=off, runtime-debugging=on)
I tried adding these lines to the clang-win.jam file: toolset.flags clang-win.compile C++FLAGS <exception-handling>on/<asynch-exceptions>off/<extern-c-nothrow>off : "" ; toolset.flags clang-win.compile C++FLAGS <exception-handling>on/<asynch-exceptions>off/<extern-c-nothrow>on : "" ; toolset.flags clang-win.compile C++FLAGS <exception-handling>on/<asynch-exceptions>on/<extern-c-nothrow>off : "" ; toolset.flags clang-win.compile C++FLAGS <exception-handling>on/<asynch-exceptions>on/<extern-c-nothrow>on : "" ; but the command line was still called with the /EHs option from the inherited msvc.jam C++FLAGS.
On 19/11/2013 16:48, Quoth Edward Diener:
There are 4 lines of C++FLAGS
toolset.flags msvc.compile C++FLAGS <exception-handling>on/<asynch-exceptions>off/<extern-c-nothrow>off : /EHs ; toolset.flags msvc.compile C++FLAGS <exception-handling>on/<asynch-exceptions>off/<extern-c-nothrow>on : /EHsc ; toolset.flags msvc.compile C++FLAGS <exception-handling>on/<asynch-exceptions>on/<extern-c-nothrow>off : /EHa ; toolset.flags msvc.compile C++FLAGS <exception-handling>on/<asynch-exceptions>on/<extern-c-nothrow>on : /EHac ;
How is a particular one chosen ?
I've never really looked into it, but it's pretty clear from the above that it will select whichever line matches the AND-combination of the settings on that line. So eg. you'll get /EHs if exception-handling=on and asynch-exceptions=off and extern-c-nothrow=off. As for those settings, they'll either be defined in project-config.jam or one of the library, compiler, or builtin jam files. (Presumably searched in that order.) But that's just a guess.
On 11/18/2013 11:08 PM, Gavin Lambert wrote:
On 19/11/2013 16:48, Quoth Edward Diener:
There are 4 lines of C++FLAGS
toolset.flags msvc.compile C++FLAGS <exception-handling>on/<asynch-exceptions>off/<extern-c-nothrow>off : /EHs ; toolset.flags msvc.compile C++FLAGS <exception-handling>on/<asynch-exceptions>off/<extern-c-nothrow>on : /EHsc ; toolset.flags msvc.compile C++FLAGS <exception-handling>on/<asynch-exceptions>on/<extern-c-nothrow>off : /EHa ; toolset.flags msvc.compile C++FLAGS <exception-handling>on/<asynch-exceptions>on/<extern-c-nothrow>on : /EHac ;
How is a particular one chosen ?
I've never really looked into it, but it's pretty clear from the above that it will select whichever line matches the AND-combination of the settings on that line. So eg. you'll get /EHs if exception-handling=on and asynch-exceptions=off and extern-c-nothrow=off.
As for those settings, they'll either be defined in project-config.jam or one of the library, compiler, or builtin jam files. (Presumably searched in that order.) But that's just a guess.
I am not setting qany options myself and yet plenty of them are part of the command line. So i just want to understandf what jam file is generating them for the command line.
participants (6)
-
Edward Diener -
Gavin Lambert -
Joshua Boyce -
Lars Viklund -
Steven Watanabe -
Vladimir Prus