Opened 16 years ago

Last modified 16 years ago

#200 new defect

Synchronizing cflag/cxxflags/compileflags toolset init options and relevant feature handling.

Reported by: jurko.gospodnetic@… Owned by: somebody
Priority: minor Milestone: M13
Component: component1 Version: 2.0
Keywords: cflags cxxflags compileflags Cc:

Description

Currently Boost build has toolset initialization options named cflags, cxxflags & compileflags and regular features named cflags & cxxflags. The two are specified using a very similar (equal?) syntax but do not have the same behaviour and the difference is not clear to the end-user.

Toolset initialization parameters are handled by the common.handle-options() rule in the tools/common.jam module and there the semantics are as follows:

  • cflags ... additional flags when using a C compiler.
  • cxxflags ... additional flags when using a C++ compiler.
  • compileflags ... additional flags when using a C or C++ compiler.

On the other hand specifying cflags & cxxflags properties is handled by each toolset separately (e.g. tools/gcc.jam) and seems to have the following semantics:

  • cflags ... additional flags when using a C or C++ compiler.
  • cxxflags ... additional flags when using a C++ compiler.

Note that compileflags is not a valid feature at all.

This should be updated so that the two are in sync.

The feature names should most likely be updated then as well. Compile flags does not seem like being named precisely enough (it does not affect the fortran compiler for instance). Some examples would be:

  • cflags.
  • cxxflags.
  • ccxxflags.
  • c-flags.
  • cxx-flags.
  • c-cxx-flags.

If this is done that other toolset initialization options and features related to other languages should be checked as well so they are named consistently.

Please note though that this will most likely break backward compatibility so we might need some sort of an intermediate solution to ease the transition, e.g. adding the new behaviour but also adding a configuration option to allow switching back to the original behaviour.

Change History (2)

comment:1 by jurko.gospodnetic@…, 16 years ago

This ticket is a duplicate of ticket #76. See the original ticket for a more concise problem description.

comment:2 by jurko.gospodnetic@…, 16 years ago

An alternative suggestion made by Ilya Sokolov is to deprecate the *flags using parameters all together and use the toolset.add-requirements rule instead. This would remove the redundancy between using options and features.

Note: See TracTickets for help on using tickets.