> > I would like to replicate what nmake :PACKAGE: does without using > > nmake, since I am trying to cut down on build-system dependencies. > > This decision is partly at the behest of my colleague and partly > > because I continue to have difficulties getting bin/package to work > > the way I expect, which leads me to wonder whether I can distribute > > something based on AST that others will be able to build on systems > > different from mine. > > you will get more leverage figuring out why "bin/package make" > fails to build nmake -- I and ast-users can help with that > > one of the foundations of ast software (ksh first and then nmake) > is portability -- if it fails at then I want to know
I'm afraid that each time I approach bin/package I become overwhelmed with its complex command-line API. I last successfully built ksh from source in 2006. And although it's a petty irritation, I am continually caught by surprise when help text emerges from stderr and not stdout. I can't count how often I've typed bin/package --help | less in error. > > The ? is that I have gotten quite interested in understanding the > > details of how nmake works. I am hoping to persuade the Glasgow > > Haskell Compiler project either to switch to nmake or to incorporate > > some of nmake's good ideas into their own build system. Growing a > > formal model of nmake seems like a good next step, and :PACKAGE: is a > > not entirely random place to pull. > > a convincing argument would be to set up the entire project with nmake > for all target architectures, culminating with a comparsion between the > nmake infrastructure against the status quo Absolutely. Ideally it's a big simplification for GHC. Either way, it would be a good learning experience. Norman _______________________________________________ ast-users mailing list [email protected] https://mailman.research.att.com/mailman/listinfo/ast-users
