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 11:12 AM, [email protected] wrote:

> Whilst the default build settings for Firefox may perfectly suit the needs
> of the Firefox team, they do not neccessarily fit well with embedding hosts.
> Shared runtime libraries being a case in point. Surely non-standard builds
> can be tested in exactly the same way as any standard Mozilla Firefox release?

It's not whether they *can* be tested, it's whether they *are* tested. Most 
of the interesting bugs that are associated with minimal build options and 
unusual build configurations are not caught by automated tests, but by 
beta-scale testing in the field. That's why we strongly encourage everyone 
to use a shared configuration.

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.

> WRT 'why does this matter to you'. Religious issue perhaps. I would always
> opt for the smallest possible installation footprint. Static linking over
> dynamic to ensure minimum version hassles, with runtime support files in a
> single checksummed, versioned, archive. Much simpler installation/removal
> and much less work to verify when problems are encountered.

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

>  From the POV of development then a single static library, build
> configuration controlled by a VS project file, makes it *much* simpler to
> integrate FF. And let's not even start on debugging/spelunking the code.

Could you be more specific? You can certainly use a MSVC project file to 
build against a prebuilt SDK (downloaded from the Mozilla site, if you 
want), and the debugging information is available from the Mozilla symbol 
server.

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.

--BDS