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