Closed Bug 145333 Opened 18 years ago Closed 18 years ago

Need build-order file for bootstrap.pl embed build

Categories

(Core Graveyard :: Embedding: APIs, defect)

defect
Not set

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: mcafee, Assigned: blythe)

References

Details

Attachments

(1 file, 2 obsolete files)

Need build-order file for bootstrap.pl embed build.

First example is "string,xpcom".  These two modules REQUIRE
each other, but the string library needs to be built first.
We can reorder the modules list in the bootstrap.pl build script
by reading in a "build-order.pl" file that lists dependencies
like this:

  A, B
  string, xpcom
  ...
-> blythe for a look
Assignee: adamlock → blythe
Blocks: 143524
from 143399, mimetype needs necko built first:
necko, mimetype
okay, so the way I am going to proceed is first to get the script to output
directory level information.

the ordering heuristic will be derived from that information.
Status: NEW → ASSIGNED
ignore previous comment, meant for different bug.
Attached patch Hard ordering rules (obsolete) — Splinter Review
Request for r= sr=

Impelments one method for hard coding module order.Provides the first example.
Attached patch Hard ordering rules. (obsolete) — Splinter Review
Request for r= sr=
Same as previous patch, but removed debugging code I accidentally left in.
Allows forced ordering of module order for bootstrap.pl
Attachment #84395 - Attachment is obsolete: true
Comment on attachment 84396 [details] [diff] [review]
Hard ordering rules.

this is ok, I guess I was kind of hoping to see this in module-graph.pl - i.e.
as an option like --force-order <orderfile>

its just that most of the other ordering logic is there already...
QA Contact: mdunn → depstein
good point, alec.
will move this to the more appropriate location.
We will need these orderings as well (from bug 145338):

  png, imglib2
  jpeg, imglib2
  mng, imglib2

module-graph.pl is used to generate all.dot, then we append
to that file to add external/virtual dependencies.  Can we
do the sorting in the bootstrap file?
blythe corrected me, we can sort with meta.dot and module-graph.pl.
Request for r= sr=
New patch to do forced order in module-graph.pl instead of bootstrap.pl
Added other comments from this bug as well.
Attachment #84396 - Attachment is obsolete: true
Comment on attachment 84551 [details] [diff] [review]
force order in module-graph.pl

This is working great.	I get past the necko idl error (still some other idl
errors), and the string/xpcom and imglib2 orderings are working.
Attachment #84551 - Flags: review+
re: comment #2, building necko before mimetype now gives this error:

gmake[1]: *** No rule to make target `../../dist/lib/libnkmime_s.a', needed by
`libnecko.so'.  Stop.

ugh.  another problem now that the ordering is in place.... (comment #13).

Is there any chance we could be solving that case differently?
I'm going to need some guidance on how to proceed.
This bug at least is finished.


cvs commit: Examining .
Checking in bootstrap.pl;
/cvsroot/mozilla/tools/module-deps/bootstrap.pl,v  <--  bootstrap.pl
new revision: 1.29; previous revision: 1.28
done
RCS file: /cvsroot/mozilla/tools/module-deps/force_order.txt,v
done
Checking in force_order.txt;
/cvsroot/mozilla/tools/module-deps/force_order.txt,v  <--  force_order.txt
initial revision: 1.1
done
Checking in module-graph.pl;
/cvsroot/mozilla/tools/module-deps/module-graph.pl,v  <--  module-graph.pl
new revision: 1.21; previous revision: 1.20
done
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Where are these files located (bootstrap.pl, force_order.txt, module-graph.pl)?
Need to see them to verify this bug. I don't see mozilla/tools/module-deps/
directory.
mozilla/tools/module-deps is not part of the SeaMonkey module and
needs to be pulled seperately.
what happened to "necko mimetype" variable in force_order.txt? Was it removed
because it's not being used? 
It was removed because it was creating problems with other parts of the build.
We worked-around the original problem another way, so we undid this hack.
yeah, we expect that once we get all the modules to be fully-specfied, that this
file will be used for only very unique purposes, like the string/xpcom
dependency, where the modules are technically distinct, but are linked into the
same library

(essentially the case where there is a link-time dependency that cannot be
otherwise determined)
verified Mozilla 1.1a Gecko 20020607 pulling /module-deps

Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.