[OpenAFS-devel] Anyone actually use any of the special build targets?

[Nathan Neulinger]

Marcus Watts wrote:
> 
Looks like some of what you mentioned is already in place (the version
stuff). My patches so far are mainly making the makefiles more
consistent, making them use dependencies more where possible, and
supporting a reasonable target for make and make all. 

I was also thinking of adding a "Makefile.utils" that would include
utility targets shared by all of the other makefiles, such as part of
the make clean, etc. Standardized rule for tests, etc. 

I'm waiting for Derrick to approve the first patch, and if so, will send
a bigger one for the rest. 

I like the idea of putting a bit more smarts into the autoconf build
process, but I think that'll probably be best for the second pass over
the Makefiles. Right now, I just want to get them condensed down to
where they MOSTLY function the way you'd expect, can worry about the
rest later.

-- Nathan

> Derrick J Brashear <shadow@dementia.org> writes:
> ...
> > I know there are people who built AFS (IBM AFS) piecemeal to get bits they
> > needed; I don't know if those people still have reasons to not do complete
> > OpenAFS builds, and if they do:
> >
> (and someone else wrote):
> > > At the very least, I want to get things to where you can reasonably type
> > > "make" all by itself, in any directory in src, and have it do something
> > > useful.
> >
> > if this wouldn't satisfy them.
> ...
> 
> I know I went to some effort with AFS 3.3a/3.4 to fix things so that
> I could type just plain "make" in any subdirectory, have it default
> to doing "make all", and do something useful.
> Transarc had
>         AFS_component_version_number.o: AFS_component_version_number.c
> all over in every makefile at the start, so that had to be moved (and I
> think I got rid of actually building and using this file, as it wasn't
> really useful to me.)  I don't know how useful building things pieceways
> would be to someone who is just building the whole thing, but to
> someone (like me) who wanted to do serious work on one piece, it's a
> real timesaver not to have to watch it not build all the rest to catch
> one stupid syntax error.
> 
> I didn't use autoconf for this -- instead, I had each makefile include
> "../config/Makefile.version", and I had stuff in the config directory
> that linked Makefile.version to a file that defined common top level
> things for the stuff that each makefile had to know about.
> Makefile.version may have originally included the transarc code to make
> AFS_component_version_number.c, but I didn't feel any shame in putting
> machine configuration defines in it instead.  This included things like
> "-lnsl -lsocket" for solaris, and also AR,NM,STRIP etc. so that I
> could cross-compile for a few platforms.
> 
> I also had to figure out what order to build things, to get the dependencies
> right... I think I ended up with a completely customized and rather
> stupid top level makefile that had targets for "all", "install", and
> "clean", that built things in this order:
>         config pinstall util mitdes comerr cmd lwp rx rxgen fsint \
>         sys ubik rxkad audit auth ptserver afs kauth log libacl \
>         dir vol vfsck vlserver volser bozo finale viced login \
>         ftpd43+ fsprobe xstat venus export $(libafs)
> 
> I don't think I actually ever got the kernel stuff to build
> this way -- I discovered this really horrible makefile that got
> run from 2 different directory levels and didn't manage to
> cleanly separate that weirdness out into 2 separate files.
> I do remember teaching "config" about <-sun4m_53> type targets
> so that I could have lines like this in libafs/MakefileProto:
>         <all -sgi_50 -sgi_51 -sgi_52 -sgi_53>
> if you're still using config with autoconf, this might be a useful
> trick.
> 
>                                 -Marcus Watts
>                                 UM ITCS Umich Systems Group
> _______________________________________________
> 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