Re: Programmer Challenge: Worlds Smallest Gecko Browser DLL for C++ programmers to use in their apps? (programmatically controlled, ultra minimalistic-->ultra fast)

  On 09/08/2010 16:31, Benjamin Smedberg wrote:
> In any case, you'd be signing yourself/your company up for lots of 
> additional testing work for a goal which isn't shared by the Mozilla 
> community. That makes little sense from an economic perspective.

That's my call. Not yours. The up front build/test cost may be way less 
than the downside support costs.

> We are trying to reduce the number of support files we ship using 
> omnijar packaging, but that is an effort to improve performance across 
> the board.

Indeed. omnijar & friends is a very worthy effort and is to be 
applauded/supported as much as possible.

> But saying that there should be *no* shared libraries is not yet a 
> realistic goal. NSS, for example, requires shared library 
> configurations by default for proper functioning. 

Agreed.

> If you mean that you want to build mozilla itself using a MSVC project 
> file, that is not a realistic goal right now and I will not accept 
> patches of that sort. It would require transforming all of our 
> existing build logic using something like gyp or cmake, which is a 
> monumental task.

I agree 110% - the Webkit/Chrome build system shows just how much 
resource is required to keep things up to date. You need to be Google.

My notion is that the standard make-driven build process generates a VS 
project file. Thus no additional dependencies or maintenance required.  
In a corporate context I'd expect one dev/make monkey to generate said 
VSP for use by relevant team members.

This would not only offer much better flexibility re VS versions 
(2005/2008/2010 all now in wide deployment) but means compilation times 
are slashed compared to bash/make/cl invocations. Have you seen how 
quickly VS2010 runs on the right kit? Oh. Then we can also use the 
profiling tools ...

Please bear in mind that using VS projects is not just about 
simplicity/speed of adoption, it also has tremendous rewards in terms of 
tooling and automation - most notably with tools like Visual Assist. 
These make code navigation a snap and offer a massive boost to 
understanding component relationships etc.

This, in turn, would/should mean a virtuous circle for Mozilla 
development too. Easier code navigation plus faster compile times in a 
highly productive and familiar environment is definitely likely to mean 
more bug fixes and code optimisations ...

Jerry