[EMAIL PROTECTED] wrote on Fri, 16 Feb 2007 19:07 -0600:
> I think a while back we changed the make dist process to not
> include .c files, but still generate the sources for statecomp
> from the lex/yacc files. So if necessary, we should still be able
> to generate the statecomp sources from one machine, and not
> require flex/bison elsewhere on the deployment machine. I'm not
> sure this is the BGL issue you're describing though...
Oh, thanks for pointing that out. I see in maint/make-dist.sh that
DIST_RELEASE is used to protect both the yacc/lex outputs and the
sm outputs. I was thinking about cross-compilation for a different
architecture where statecomp needs to run on the build machine, not
the target (some wacky embedded architecture or high-perf machine).
Just wanted to make sure my patch didn't break any of these
situations. I think it doesn't.
> >3. Remove dependency of "%.c: %.sm" on statecomp. This causes
> > massive rebuilds everytime you recompile statecomp, but is kind
> > of misleading I think. We don't force rebuilds if the Makefile
> > or module.mk.in change, or if the gcc version changes. Building
> > statecomp is for the hard-core who know how to test their changes
> > by rebuilding generated .c files by hand.
> The few times I've ever changed statecomp it was to change the
> generated as well, so I would have always wanted to have this
> dependency. Though doing make clean for the few cases where
> statecomp gets changed isn't a big deal either. What are you
> changing in statecomp that doesn't result in changes to the
> generated files? Just restructuring and cleanup?
I keep forgetting to "declare" a new state in the machine line.
smcgen touches the output file, but exits with error. Make gets
confused. I was planning to rip out the need to pre-declare these
states but got sidetracked into build issues of statecomp itself.
Note: "make clean" doesn't remove the SMC generated files, but it
does remove statecomp generated sources. DIST_RELEASE changes this
behavior to leave around the statecomp generated sources. Just fyi.
> What happens if I don't compile everything first, including
> statecomp, and try to modify a .sm and then try to get the .c
> generated by trying to make that one .c target? Won't the thing
> barf because the statecomp binary doesn't exist? Honestly, I
> can't imagine this ever happening in practice, and since its the
> only counter-example I could think of, I guess this change is ok.
Yes, it barfs. I'll put the dependency back. Too confusing to see
all the command-not-found errors. If we edit statecomp sources, SMC
and DEP get run across all the .sm files. It's bearable and lots
easier. Thanks for the comments.
-- Pete
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
