[ruby-core:33843] Re: trunk warnflags build issue with curb 0.7.9?

> > As this may turn out to be a 3rd party issue rather than a bug, I'd like some feedback.
> 
> It's a bug in curb.
> 
> > compiling curb_postfield.c
> > curb_postfield.c: In functioon 'ruby_curl_postfield_to_str':
> > curb_postfield.c:446:5: error: ISO C90 forbids mixed declarations and code
> 
> I think the error message explains it completely.
> 
> > # curb_postfield.c:446
> >   char *tmpchrs = curl_escape(StringValuePtr(name), (int)RSTRING_LEN(name));
> 
> > Does core consider the above code snippets to be incorrect?
> 
> Definitely incorrect.

This is a very productive, elegant, and clever commit. It opens the door to enabling two logical build environments: "pre-install builds" (eg - building ruby proper) and "post-install builds" (eg - downstream native gem builds using an installed ruby) in which each can be tuned appropriately.

For pre-install builds, failing fast (for CI, etc) using existing tool features is a great way keep the core codebase consistent with minimal burden. However, I'm not sure that allowing these more rigorous requirements to leak downstream is a good thing. From the commit itself, it's unclear whether the downstream effects were an unintended consequence or purposeful.

In the case of curb, IMO it's the gem authors responsibility (not core) to decide whether to support building their gem via VC. I also think that core shouldn't be overly constrained by the downstream when working to enhance the codebase usability and robustness. For these reasons I favor viewing the build as two complementary parts rather than a monolithic whole. I view the commit a great first step.

Perhaps this commit can be expanded by implementing filtering of build constraints from the pre-install build environment to the post-install build environment?

Specifically, could configure.in, mkconfig.rb, etc be updated to filter build settings when rbconfig.rb is created?  When building ruby itself, a more stringent environment is in place, but some of these constraints (such as -Werror=declaration-after-statement) not be injected into RbConfig::CONFIG so as to not overly constrain downstream builds?  What are the downsides to this approach?

Jon

---
http://jonforums.github.com/