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

On 8/9/10 12:00 PM, [email protected] wrote:

> 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 ...

I think we're fully off-topic now, so the rest of this discussion should 
head to mozilla.dev.builds.

We could spend significant energy making a system that produces MSVC project 
files and integrates tightly with tools such as Visual Assist. Or we could 
spend time solving the same problems in a cross-platform manner that helps 
all of our developers. I hope it is an obvious decision that we have taken 
the latter path.

With tools such as DXR, you can browse the code in your web browser 
<http://dxr.mozilla.org/>. This same static analysis data can be hooked into 
context-sensitive development environments such as emacs or Komodo.

We have also spent significant energy making builds much faster on Windows 
with pymake and native commands, to the point where soon a windows build 
will probably faster using pymake than it would be as a native project file.

--BDS