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 _______________________________________________ dev-embedding mailing list [email protected] https://lists.mozilla.org/listinfo/dev-embedding
