The library setup under layout, dom, and widget involves building a bunch of small static libraries which are then combined in directories called "build" into bigger dynamic libraries. The problem is that there are no dependencies on the static libraries in the build/Makefile, so anyone trying to develop on linux must understand this structure, build their smaller library, know exactly where to find the appropriate "build" directory, cd there, rm lib*, and then make there. This drastically raises the bar to accomplishing anything as a Mozilla developer on Linux, especially since none of this is documented anywhere. If we're going to keep using this system, the "build" Makefiles should have dependencies on the libraries which go into them so that a "make" from the top level actually picks up new changes.

adding briano to cc list

Sorry, but I have to add my own snotty two cents.... Why would anyone do things this way?!? If the plan is to generate a single library in the end, then why not do just that? Why waste the time and effort to generate separate libs, just to end up combining them into one? Then again, why not just use the separate libs as is? That would make the library contents "cleaner", and the make dependencies easier to follow. What am I missing here? Is this just to reduce link line clutter?

The reason it's done this way is that (a) VPATH and make don't really work, and (b) the end product is a .so not a .a. So, to avoid having duplicate lists of files (one in each dir where a .o is created, and one in the place where we construct the final .so) the current system takes the individual .a's and constructs a .so out of them. Adding in dependency rules is easy. Do you have a better solution?

assign to briano... brian can you go fix this?

Setting all current Open/Normal to M4.

I'll take this, but I won't be able to do anything about it for a while, because I'm currently more concerned with more important issues (like being able to build on more than just Linux and Windows).

per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

Akkana, is this still an issue? I've decided to ignore this process of creating big combo libs from smaller ones. It now works for both shared libs and static libs, and though I think we should either not do it this way at all, or recompile the files repeatedly for each unique "combo lib" (so the build flags and make macros match the needs of each individual component or whatever), what we have does work. And "if it ain't broke...." Closing the bug.

Brian: it's still an issue because it's a barrier to new developers wanting to get involved; it's confusing that you have to know that from some directories (widget, layout, etc.) changing a file and rebuilding the directory it's in won't actually rebuild the library that gets loaded. I have a script that climbs up the tree from '.' and looks for directories called "build" and does "rm lib*; make" in those directories; it works okay, but how do people find out they're supposed to do that? That seems like it ought to be a build system dependency rather than something that each developer has to discover the hard way and then spend a day working out how to deal with it. If the dependencies work right now (do they?) so you can cd ../build; make and have it actually rebuild the library, that would be a nice step in the right direction (because then at least builds from the top would do the right thing).