Brendan Eich wrote:
> (Warren was right; waterson shouldn't have removed the REQUIRES
> requirement!)
>
> We don't need to tyrannize header and idl files from various modules
> out of their local subtrees and into an include subtree to fix that
> bug. All we need to do is require REQUIRES. It used to work by
> segregating different modules' exportables under subdirectories of
> $(DIST)/include, and could again. There is no necessary or sufficient
> relation between REQUIRES and this
> all-public-exportable-sources-must-move-to-a-central-include-subtree
> idea. IOW, the mozilla/include/... subtree of module directories
> containing exportables for each module can exist not under CVS, in the
> repository, but as a tree of symlinks under $(DIST)/include (don't
> have symlinks? find something like them, or copy files -- or get a
> real OS! :-).
our dependencies are undefined, nasty, and hard to break (for a glimpse,
run Adam's perl script that traverses the #include tree for our
embedding samples; it ain't pretty :-( ). I'm all for bringing back the
REQUIRES requirement. very few people are as diligent as
[EMAIL PROTECTED] and do a requires build on linux (to identify any
new deps) before checking in mods.
the nest of dependencies is something we're going to be clamping down on
soon, anything that assists that effort (raising REQUIRES from the
dead???) will be welcome. back in the day of mozilla/include*, folks
assumed they could use anything in there, which led to a free-for-all
and dependencies went wild (not that they're any more tame now though :-/).
obviously "get[ting] a real OS" isn't always an option.
> What problem is really being solved here? Not the lack-of-REQUIRES
> problem -- we had that before, along with symlink-install of diverse
> headers to $(DIST)/include/<module> subdirs. If it's the slowness of
> the export phase, I'm tempted to say "get a faster machine" -- but I'd
> be open to speeding up what can be optimized. As long as we're using
> gmake and lots of pattern rules in common .mk include files, I think
> make speedups can win a lot more than tree reorgs that go against
> distributed ownership and truly standalone modularity.
please keep in mind that only linux uses gmake for the entire build
right now. windows isn't so lucky.
Jud
