lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120330052605.GA30508@merkur.ravnborg.org>
Date:	Fri, 30 Mar 2012 07:26:05 +0200
From:	Sam Ravnborg <sam@...nborg.org>
To:	Borislav Petkov <bp@...64.org>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Michal Marek <mmarek@...e.cz>,
	LKML <linux-kernel@...r.kernel.org>,
	Borislav Petkov <borislav.petkov@....com>
Subject: Re: [PATCH v3 0/4] tools: Add a toplevel Makefile

On Thu, Mar 29, 2012 at 02:25:53PM +0200, Borislav Petkov wrote:
> From: Borislav Petkov <borislav.petkov@....com>
> 
> 
> Hi all,
> 
> yet another version of the toplevel Makefile integration of tools/.
> This round gives you the ability to build the tools from the toplevel
> Makefile (explanation below can be found also in patch 4/4's commit
> message):
> 
> "Now you can do
> 
> $ make tools/<toolname>
Makes sense.
> 
> from the toplevel kernel directory and have the respective tool built.
> 
> If you want to build and install it, do
> 
> $ make tools/<toolname> tinstall
But this makes no sense.

It would be better to be consistent - so the user does not need to remember
when to add a space and when not.

make tools/<command> where <command> is one of help, install, clean, "nothing"
make tools/<toolname>
make tools/<toolname>_<comand> where command is the same set of commands


then a user could do:

    make tools/clean
    make tools/perf
    make tools/perf_install

or

    make tools/clean
    make tools/
    make tools/install


The install target could implicitly include the build target.

With this scheme the user is up to less suprises.

All the above are only minor adjustments compared to what you already did.
bt the consistency here is a gain (IMO).

	Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ