Brent Dax wrote: [...] > In the long term, we probably should implement something like MakeMaker; > for now, however, I think we can go with a much simpler approach. > Imagine this directory structure: > > +-+parrot > +---Makefile.in > +---(other stuff) > +--+hints > +---vms.pl > +---Makefile.vms > +---(other stuff) > > Makefile.vms would be VMS's version of Makefile.in; when the VMS hints > file was called, it would copy Makefile.vms over the existing > Makefile.in. Ugly, but it'll work for now. > > Actually, now that I think about it, perhaps this trick should be > extended to all platforms--Makefile.vms, Makefile.win, Makefile.mac, > Makefile.unix, etc. There would be no regular Makefile.in--Configure > would put the right one into place before generating the Makefile.
But this means all the Makefile.* files need to be kept in sync with the same data but in their own particular flavors. (Does the mac have a Unix compatible make?) I think eventually we're going to have to specify things generically and have OS specific translators convert to the appropriate (Makefile|descrip.mms|macthingy). On the one hand, it make some sense for the generic version to be a Makefile, so the Unix based translation is near a noop. But all it takes is for someone to put a $(CC) $(CCFLAGS) -o $@ or some other Unix only thingy in the template and everyone else is hosed. And there may be some platform specific idiom somewhere that just won't translate to Makefile syntax. Still, this approach has appeal. The gripping hand danger is that we might go off half-cocked trying to write the Ultimate Platform Independent Build System. It might not be too hard, after all, it's just targets, dependencies, actions, and substitutions. But if it were that easy, why hasn't it been done? Brad
