[procps] Re: procps changes

  • From: Sami Kerola <kerolasa@xxxxxx>
  • To: procps@xxxxxxxxxxxxx
  • Date: Thu, 29 Sep 2011 09:49:32 +0200

On Thu, Sep 29, 2011 at 09:06, Jim Warner <james.warner@xxxxxxxxxxx> wrote:
> I found the source of my permission problems.  My umask was 0027 whereas 
> root's umask was 0022.  But shouldn't install ensure proper permissions on 
> the directories it creates rather than rely on whimsy?

AFAIK the install does what posix compliant program is supposed to do;
at file/directory create set permission as umask tells they should be
set. It could be possible to change modes after install run with
install-hooks, but I recommend not to do that. The umask is there for
the purpose of controlling how permissions are set.

> Please forgive my ignorance, but there are some additional questions I would 
> deeply appreciate help on.
>
> 1) Can I somehow produce stripped programs during an install?

make install-strip

> 2) Is it possible to pass make a define similar to 'gcc ... -DOOM_ENABLE'?

-- snip
./configure --help
[...]
Some influential environment variables:
  CC          C compiler command
  CFLAGS      C compiler flags
  LDFLAGS     linker flags, e.g. -L<lib dir> if you have libraries in a
              nonstandard directory <lib dir>
  LIBS        libraries to pass to the linker, e.g. -l<library>
  CPPFLAGS    (Objective) C/C++ preprocessor flags, e.g. -I<include dir> if
              you have headers in a nonstandard directory <include dir>
  CPP         C preprocessor
-- snip

So in your case

CFLAGS="-DOOM_ENABLE" ./configure

For instance some interesting messges become visible when you build with

CC="clang"

or

CFLAGS="-pedantic -Wall -Wextra"

Please notice that OOMEM_ENABLE should be converted to autotools
directive such as

./configure --enable-oomem

I have not investigated enough the package that I would know which
preprocessor things should be converted to something that config.h can
support. That should be done once the initial autotools set up is part
of upstream. BTW is this a blocking item what comes to a release?

> 3) How do you personally determine all possible targets in an unfamiliar 
> Makefile?

I would simply read the file with less. Although I need to admit that
autotools make quite messy Makefile, and most of the targets are
useless for great majority of people. Luckily the most useful targets
are listed in manual.

http://www.gnu.org/software/automake/manual/automake.html#Standard-Targets

> p.s. For what its worth, your ng branch merges flawlessly with the current 
> master.

Thank you for acknowledgement. Is it time to merge, or has someone
found something other worth to mention?

-- 
   Sami Kerola
   http://www.iki.fi/kerolasa/

Other related posts: