[OpenAFS-devel] Call for consensus: configure defaulting behavior change

[Nathan Neulinger]

Only comment I'd have to make about it is that it will require
significant changes throughout the build system since alot of the build
process depends on libraries/headers/etc. being installed into
particular destination directories for part of the build process.

What I'd suggest instead is renaming the current 'install' target (i.e.
rename to 'build'), and making a new 'make install' that installs from
the dest dir (treat like an objdir) into the destination dirs that you'd
expect according to prefix.

BTW, Some of this will be alot easier after next release and application
of some more makefile patches. 

-- Nathan

Sam Hartman wrote:
> 
> Now that AFS supports configure, people probably expect to be able to
> use the --prefix argument and other path control switches to  change
> where AFS puts files and  where it expects to find them at runtime.
> Clearly we will want to support the current paths now.  Most existing
> users will continue to  use the Transarc style paths or whatever
> site-specific modifications they have been using.
> 
> I suspect that new sites may start to use paths that better model how
> other free software (or how software on their OS) works.  It seems
> likely that we will want to support both path styles.  I have been
> working with Jeff Hutzelman on the directory issues that are involved
> in this proposal.  I hope to have a patch ready soon.  However  I need
> to get a consensus from the group on  one issue  before I submit a
> completed patch.
> 
> As I mentioned we will need to support the Transarc paths because many
> people will use them.  However, I would like to make more traditional
> configure paths be the default.  The reason I'd like to do this is
> that I want the software to behave as people who are familiar with
> configure expect.  There would then be an --enable-transarc-paths
> option that would get the traditional AFS behavior.
> 
> The major objection I can see to my proposal is that I'm breaking the
> behavior for people who are familiar with AFS in order to make things
> work like configure traditionally works.  I argue that AFS hasn't
> really used configure that long .  I hope that people are willing to
> accept adding an extra argument to configure in order to get the
> behavior they expect from AFS.  Does this seem reasonable?
> 
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel

-- 


------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul@umr.edu
University of Missouri - Rolla         Phone: (573) 341-4841
CIS - Systems Programming                Fax: (573) 341-4216