This means we can include those headers without needing chromium-config.mk in the makefile.

This seems like a really bad idea.

Yeah, not really the best idea ever. (and see why bug 907683 was backed out for extra fun)

Can one of you guys clarify why you think it is a bad idea? Is it just that we're worried about things including the wrong headers as in 907683? I would hope that could be shown one way or the other with a try job. If we don't go with this approach, what would you suggest? Should we just port the chromium-config.mk logic to a chromium-config.mozbuild file?

(In reply to Michael Shal [:mshal] from comment #4) > Can one of you guys clarify why you think it is a bad idea? Is it just that > we're worried about things including the wrong headers as in 907683? I would > hope that could be shown one way or the other with a try job. I think that's a concern, but I also think most/all of the ipc/ stuff is low-level code that we shouldn't be treating as part of our SDK. Significant chunks of it (e.g. the atomicops stuff, the base_path stuff, timers, string bits, scoped pointers) we already implement elsewhere and people should be using those bits instead. Some things people shouldn't be touching at all (message pumps, thread bits). It's mostly a philosophical objection. > If we don't go with this approach, what would you suggest? Should we just > port the chromium-config.mk logic to a chromium-config.mozbuild file? I think that could work.

It's been quite a while since "it's exported" meant "embedders can touch it", though.

(In reply to :Ms2ger (away 11-21 September) from comment #6) > It's been quite a while since "it's exported" meant "embedders can touch > it", though. Oh, really? Neat. Still, I don't think we want to make all that stuff available for anybody in Gecko to use; only small portions should be using chromium bits.

Ms2ger, what are your thoughts on keeping the logic as-is, but just putting it into a chromium-config.mozbuild file?

(In reply to :Ms2ger (away 11-21 September) from comment #6) > It's been quite a while since "it's exported" meant "embedders can touch > it", though. That's not a reason to add more to dist/include.

I don't think it makes sense to have half the tree have access to these headers and half the tree not have access.

Comment on attachment 802231 [details] [diff] [review] Export chromium headers; Can you try the chromium-config.mozbuild route? If that seems more difficult maybe we can revisit this approach.

Sorry, I have no interest in trying that route.