Ethereal-dev: Re: [Ethereal-dev] patches for config.nmake and Makefile.nmake

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: aferen@xxxxxxxxxxxx (Andrew C. Feren)
Date: 24 Jan 2002 17:06:56 -0500
Hamish Moffatt <hamish@xxxxxxxxxxxx> writes:

> On Thu, Jan 24, 2002 at 03:52:37PM -0500, Andrew C. Feren wrote:
> > config.nmake:
> > changed POD2MAN=pod2man back to POD2MAN=$(PERL) $(UNIX_BIN)\pod2man
> > 
> > POD2MAN=pod2man only works by default in environments with a
> > pod2man.bat script.  The later should work with or without the
> > pod2man.bat.
> 
> pod2man.bat is part of the standard ActiveState Perl installation.
> I don't understand why you wouldn't have it (and hence why we
> can't depend on it).

        I got my perl.exe as part of a cygwin install.  I have never
        installed perl as a separate package.  I searched my entire
        drive for pod2man.bat and found nothing.

        I suppose I could add my own, but that just means one more
        thing to do the next time I configure a machine for me or
        someone else.  

        Is there a compelling reason that relying on pod2man.bat is
        better than calling perl with pod2man as an argument.  Perhaps
        I am missing something.

> Further, where is $UNIX_BIN defined?
> Before I changed this in a previous patch, it had the path to
> Perl hard-coded, from memory. That is probably just as good
> as a non-standard environment variable. config.nmake is intended
> to be customised on each build system.

        I debated that one a little bit.  It is contrived.  

        The only advantage is you potentially only need to edit one
        line instead of several.  Having the variable name also makes
        it somewhat self documenting as to why that entry is in the
        PATH.

> > Added the notion of TOP macro (requires cooperation from Makefiles) so
> > the wiretap DLL can be found in the current build directory rather
> > than an arbitrary hard coded path.
> 
> $TOP will be hard coded, though?

        Hard coded with a relative path which will be correct for any
        ethereal build regardless of the absolute path of the top of
        the build directory.

> > Used $(COMMONPROGRAMFILES)\gnu in the path to find iconv etc.  Since
> > this seems to be set by the system I figured it couldn't hurt to use
> > it.
> 
> Is it set on Win95/95/ME?

        Honestly I don't know.  This is a good point.  If not my
        preference would be to place a line like:

#COMMONPROGRAMFILES=c:\Program Files\Common Files

        the line can be uncommented as needed.  But, perhaps you are
        correct that in this case the hardcoded path is as good as
        anything.

> regards,
> Hamish
> -- 
> Hamish Moffatt VK3SB <hamish@xxxxxxxxxx> <hamish@xxxxxxxxxxxx>
> 
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
> 

-- 
-Andrew Feren
 Cetacean Networks, Inc.
 Portsmouth, NH