I have to say the 'global makefile' thing rarely works - there
are too many platforms/makes out there. As someone who uses
odd platforms (Ultrix, OpenBSD on (MIPS|Alpha|Sun|Apple), and
not Linux), I really hate the 1991 flashbacks of editting .h
files and Makefiles (or Perl's Configure).
Autoconf does a lot of that work for us and leaves a nice
"config.h" that has the platform specific needs to work with.
Let the user choose to disable TCP wrappers at an easily
reproduced "./configure" line. Things like that.
Recall that the common use of this is to build it and move on
with life for 6 months, a year whatever. Then to come back and
try to figure out how we built it before when we need to
upgrade. Me? I keep around the ./configure lines in a build
area with the tar.gz files (EG: netatalk-1.4b2-configure, or
gzip-1.2.4-configure).
The hard work has been done with autoconf. It's also an interface
admins are familiar with -- and for those of us who compiled OSS in the
late 80's and early 90's, one that we are grateful for.
Just my views,
chuck
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
> > From: a sun <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
>
> > when i get all of the kinks out of the code, i usually turn off most
> > of the options. that usually makes it easier to compile. i do tend to
> > leave the tcp wrapper stuff on though. having a little configure
> > script that does feature tests and goes through and edits the Makefile
> > for you would be ideal.
>
> I recently built asun 2.1.3. My largest complaint is how difficult it
> was to build correctly. I agree that tcp wrappers should be the
> default for the AFP/TCP support. I'm not in favor of configure
> scripts. I think most decisions can be made with only the system
> version. In the case of Linux, I think we should probably be creating
> RPMs, since version skew is so rampant.
>
> > anyways, i'd be more than happy to get
> > prototypes and stuff for the code to incorporate.
>
> Well, let's try to focus on making this frozen version netatalk 2.0.
> That, I think ought to include a source review/update for
> ansi/posix/modern coding standards.
>
> :wes
