Re: build problems with latest cvs



Marc Lehmann said:
On Mon, Dec 15, 2003 at 10:26:57AM -0500, Ross McFarland <rwmcfa1 neces com>
wrote:
podifystockitems.pl is the point at which things die rather than ParseXSDoc.

ah :)

it does indeed require Gtk2 to be working (at least in the blib dir,) but it
should not be run until the pod2man step which (on linux/x86) is after all
of
the compilation as part of manifying things.

Hmm.. I fail to see why the pod2man step should be after compilation.
Was an explicit dependency added?

I mean, there is no (logical) dependency between compilation and
manifying, so I would be a bit surprised if MakeMaker would add an
unneeded one (in the cases of Gtk2 it's needed, but normal modules
obviously don't need one).

there may be no reason for it to, but that is the order of things enforced by
make maker.

*** Makefile
all :  pure_all manifypods

pure_all, which happens first does just about everything. and manifypods calls
pod2man to manify pods. we added pods to the list (of manifypods deps) that
don't exist and then rules to make them so before manifypods can happen those
pods are created.

try make -j or make -j3 or somesuch. The problem might be hidden on your
machine because the order of jobs started might "just work out right",
while in other circumstances (different make, different timing, parallel
builds etc.) podifystockitems gets run before the compilation is finished.

tried, even on a dual proc system and nothing was different for me. all of the
xs build completed and then the pod generation and manifying happened.

even more, manifypods depends on pure_all as it's very first dep. which, no
matter what -j you give it cause manifying to wait for pure_all to complete
before doing the other pods and thus podifystockitems.pl are done (pure_all
includes making blib/arch/auto/Gtk2/Gtk2.so)

*** Makefile
manifypods : pure_all \
        first_pod_file_dep.pod \
        ...

If there really is a dependency from running podifystockietms to the
linking process, then the bug must be elsewhere, as this clearly happens
long before linking is being done.

the only way i've been able to recreate similar behavior to what you saw was
to truncate the Gtk2.so file in blib/arch/Gtk2/ so that there's one there, but
it's invalid. since there's (an invalid and newer than the .o files) one there
it doesn't get built before the podifystockitems.pl step, which fails with a
different but equivilent message, that the file has zero size.

if i make all. then delete blib/arch/auto/Gtk2/Gtk2.so, then make again
Gtk2.so gets rebuilt before the podifystockitems/GenPod steps occur, even with
-j 4. it makes Gtk2.so, then goes on to the

so basically podifystockitems.pl already depends on Gtk2.so through manifypods
first dependancy being pure_all. i'm not trying to say what you saw didn't
happen, but i can't see how it could of. bascially the only situation i can
see now would be there was an old Gtk2.so file in blib/arch/auto/Gtk2 with a
timestamp newer than all of the .o files in xs/.

-rm



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]