...but the less external dependences the better.
Sounds good but OTOH this would mean less use of shared dlls which leads to more memory usage. And memory is getting more and more a scare resource on our OS. So sooner or later this will lead to more trouble than solving in the short term.
A couple of points about this, the gcc dlls are very small and there is likely more overhead loading them then is saved by having them in a dynamic library. Even the bigger DLLs such as mzfntcfg are statically linked to xul.dll so it seems they'd still be in shared memory.
As well my understanding is that each program gets its own private memory arena whereas shared is shared though we do have high memory now.
Personally it is the small dlls such as the gcc ones that I find irritating and even on Windows developers usually statically link them.
It saves us having to try and find the odd DLL and put it where it won't cause trouble at a later date.
This should not be much of a problem. Only install what the readme says. Or is there some dll missing in the readme?
Usually we seem to miss at least one and sometimes there is a surprise such as old exceptq.dll breaking SM
It also means that what you build is much more in the OS/2 way which is 'a good thing'.
Avoid using shared dlls contradicts the 'OS/2 way' IMHO.
Is having so many dependencies really the OS/2 way? Before Bitwise the developers in charge of Mozilla, first IBM, then Peter and Rich always strived to have the least dependencies as possible. I remember reviewing the source of GCC 3.4.5 to see if we could legally load the gcc345.dll statically and after getting Knut to update the license on his code (GPL with linking exception) Peter kept the dependency limited to libc
Dave, I clearly vote for one 'standard way'. At this times as defined by bww.