Well, I didn't go nearly far enough into the caves on that spelunking trip...
XCFLAGS and XLDFLAGS appear to be reset, and not inherited from the environment either. Short of post-processing the auto-generated Makefiles, and adding the necessary paths to each place they are needed, is there a generic mechanism for seeding these variables with arbitrary values? On Fri, Oct 1, 2010 at 9:03 AM, Phillip Moore <[email protected]>wrote: > Since it has become painfully clear to me just how atrophied the Quick > Start Guide is over the last week, I am fairly certain that the > documentation it contains regarding building OpenAFS from source probably > suffers from similar neglect. > > Before I start banging my head again that particular wall, can someone > please point me at the latest and greatest available documentation on how to > compile the latest 1.5.77 release? > > I've already found one difference between the OpenAFS configure > infrastructure and most other GNU configure based projects. The OpenAFS > configure is not respecting the existing definitions of CFLAGS, LDFLAGS, > etc. and adding to them. Normally, when I need to coerce a configure-based > build into using extra paths, the code I wrote which automates these > installs simply calculates the necessary values, exports them, and then runs > configure. > > That's clearly not working for OpenAFS (my ncurses is in non-standard > location, just like everything else I build into EFS), and some quick code > spelunking suggests that I need to set XCFLAGS and/or XLDFLAGS instead > (looking at src/config/Makefile.config.in). > > I am hoping that this, and other build-related lore, is documented > somewhere. > > >
