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

Status: VERIFIED FIXED

(Core Graveyard :: Embedding: APIs, defect)

Description

[Chris McAfee]

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

Comment 1

[Chris McAfee]

-> blythe for a look

Comment 2

[Chris McAfee]

from 143399, mimetype needs necko built first:
necko, mimetype

Comment 3

[Garrett Arch Blythe]

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.

Comment 4

[Garrett Arch Blythe]

ignore previous comment, meant for different bug.

Comment 5

[Garrett Arch Blythe]

Attachment: Hard ordering rules

Request for r= sr=

Impelments one method for hard coding module order.Provides the first example.

Comment 6

[Garrett Arch Blythe]

Attachment: Hard ordering rules.

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

Comment 7

[Alec Flett]

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

Comment 8

[Garrett Arch Blythe]

good point, alec.
will move this to the more appropriate location.

Comment 9

[Chris McAfee]

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?

Comment 10

[Chris McAfee]

blythe corrected me, we can sort with meta.dot and module-graph.pl.

Comment 11

[Garrett Arch Blythe]

Attachment: force order in 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.

Comment 12

[Chris McAfee]

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.

Comment 13

[Chris McAfee]

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.

Comment 14

[Garrett Arch Blythe]

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.

Comment 15

[Garrett Arch Blythe]

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

Comment 16

[David Epstein]

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.

Comment 17

[Chris McAfee]

mozilla/tools/module-deps is not part of the SeaMonkey module and
needs to be pulled seperately.

Comment 18

[David Epstein]

what happened to "necko mimetype" variable in force_order.txt? Was it removed
because it's not being used? 

Comment 19

[Chris McAfee]

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.

Comment 20

[Alec Flett]

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)

Comment 21

[David Epstein]

verified Mozilla 1.1a Gecko 20020607 pulling /module-deps