This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: need finer-grained "C" header scheme information


> Which parts of the model?  Is there a convenient name we can give to a
> feature set so that configure.target can do
> 
>     switch $target_os in
>         weird8.2)
>           c_headers_get_special_treatment=yes ;;
> 
> and then GLIBCPP_ENABLE_CHEADERS can examine
> c_headers_get_special_treatment? Probably more than one such variable
> would be needed with this route, but if the defaults are wisely chosen
> it shouldn't be too onerous.

Hmmm. Basically, I need to move the default argument for 

acinclude.m4's GLIBCPP_ENABLE_CHEADERS

into configure.target. Then, I need an additional switch to flip if "C"
compatibility headers are to be used.

something like:

# defaults
c_headers_used = c_std
c_compatibility_headers_used = no

# per-target-overrides
switch $target_os in
         qnx6.[1,2])
           c_headers_used = c
           c_compatibility_headers_used = no
	newlib-based-crosses)
          c_headers_used = c
          c_compatibility_headers_used = yes


??

make sense?

Is it always assumed that configure.target bits are active before
acinclude.m bits are used?

-benjamin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]