Re: make includes

2002-10-07 Thread Mark Murray

 I made `includes' and then `libraries'.
 Now `buildworld' succeeded! Thanks.
 
 How did you know this?

I read the makefiles.

 Is there a guide how to upgrade from stable to current?
 (src/UPDATING only mentions something about /usr/include/g++.)

No. CURRENT is not really documented that way. Developers are supposed
to Use the Source, Luke! :-)

M
-- 
o   Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Skipping certain buildworld stages (was: Re: make includes)

2002-05-16 Thread David O'Brien

On Thu, May 16, 2002 at 09:07:25AM +0300, Ruslan Ermilov wrote:
 it's possible to achieve this with:
 
 : make \
 : -DNO_worldtmp -DNO_bootstrap-tools -DNO_cleanobj -DNO_obj \
 : -DNO_build-tools -DNO_cross-tools \
 : buildworld TARGET_ARCH=foo
 
 Which in essence is equivalent to this sh(1) script:
 
 : cd /whatever/usr/src
 : for target in _includes _libraries _depend everything; do
 : make -m `pwd`/share/mk -f Makefile.inc1 \
 : ${target} TARGET_ARCH=foo
 : done

Thanks!

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: make includes

2002-05-15 Thread Ruslan Ermilov

On Tue, May 14, 2002 at 12:18:14PM -0700, David O'Brien wrote:
 On Tue, May 14, 2002 at 04:10:51PM +0300, Ruslan Ermilov wrote:
   Why change in the first place?
   
   What was wrong with 'make includes'? Why break POLA?
   
  They were broken.  See commit log for share/mk/bsd.incs.mk,v 1.1 for
  a full story.
 
 I fail to see how they were broken from the rev 1.1 bsd.incs.mk log.
 
Please read it more carefully.  (Hint: not all includes have been
installed).

 It looks like you just hyjacked the `includes' target.  Why could you not
 have used `incbuild' and `incinstall'?  Then includes is something like
 
 includes: incbuild incinstall
 
Actually, from what I've read, I plan on renaming these targets to
buildincludes and installincludes, and restoring the `includes' to
mean build + install.  I will do the same for all-man, maninstall
(buildmanpages, installmanpages, manpages = build + install), etc.
all would mean build* (build everything), and install = install*
(similarly install everything).  This would bring us the consistency
in standard targets names, so that one doesn't need to remember
that to all-man is build manpages, and includes - to build includes,
and files (when we have bsd.files.mk) to build files.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age



msg38359/pgp0.pgp
Description: PGP signature


Re: make includes

2002-05-15 Thread Ruslan Ermilov

On Tue, May 14, 2002 at 06:43:01AM +, Hiten Pandya wrote:
 --- Ruslan Ermilov [EMAIL PROTECTED] wrote:
  People might want to use it like that:
  
  make world
  mv /usr/include /usr/include.old
 
 Sorry to butt in; but wouldn't it be more good if this step was done
 by the build scripts itself? (refering to: mv /usr/include /usr/include.old)
 
  make incsinstall
 
Nope.  Some of us have custom stuff in /usr/include, and we can't force
everyone to fix it by moving it under /usr/local/include.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age



msg38360/pgp0.pgp
Description: PGP signature


Re: make includes

2002-05-15 Thread Bruce Evans

On Tue, 14 May 2002, David O'Brien wrote:

 On Wed, May 15, 2002 at 12:38:49PM +1000, Bruce Evans wrote:
   I really do not like this change, please return things such that the
   long-ingraned cd /usr/src ; make includes.
 
  I planned to fix this by changing make includes to print
  Unwarranted chumminess with implementation.

 What is your perfered way to get the results of
 (cd /usr/src ; make includes) ?

I prefer not to do this.  There are simpler methods to get broken
headers, starting with rm -rf :).  I prefer everyone to use (documented)
user-level targets like world and install for installing includes,
since it would be difficult to make the includes target safe for general
use.  I don't know what it really useful for.

Bruce


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: make includes

2002-05-15 Thread David O'Brien

On Wed, May 15, 2002 at 05:05:02PM +1000, Bruce Evans wrote:
 I prefer not to do this.  There are simpler methods to get broken
 headers, starting with rm -rf :).  I prefer everyone to use (documented)
 user-level targets like world and install for installing includes,
 since it would be difficult to make the includes target safe for general
 use.  I don't know what it really useful for.

`make includes' has been *invaluable* to time many times.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: make includes

2002-05-15 Thread David O'Brien

On Wed, May 15, 2002 at 09:59:19AM +0300, Ruslan Ermilov wrote:
 Actually, from what I've read, I plan on renaming these targets to
 buildincludes and installincludes, and restoring the `includes' to
 mean build + install.

Thank you.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: make includes

2002-05-15 Thread Ruslan Ermilov

On Wed, May 15, 2002 at 05:05:02PM +1000, Bruce Evans wrote:
 On Tue, 14 May 2002, David O'Brien wrote:
 
  On Wed, May 15, 2002 at 12:38:49PM +1000, Bruce Evans wrote:
I really do not like this change, please return things such that the
long-ingraned cd /usr/src ; make includes.
  
   I planned to fix this by changing make includes to print
   Unwarranted chumminess with implementation.
 
  What is your perfered way to get the results of
  (cd /usr/src ; make includes) ?
 
 I prefer not to do this.  There are simpler methods to get broken
 headers, starting with rm -rf :).  I prefer everyone to use (documented)
 user-level targets like world and install for installing includes,
 since it would be difficult to make the includes target safe for general
 use.  I don't know what it really useful for.
 
It's now more useful (incsinstall) than before, for developers.  Imagine
you've modified the include file foo.h and want to try if bar compiles
with it.  As incsinstall now works on per-makefile level, you can just
install this particular include (or group of related includes), and then
just cd to bar's directory, and try to make it.  It is also useful as a
standard target so we don't forget to install some includes (which might
be needed to build libraries), like we did before.

(Of course, if the header is local, one might use -I${.CURDIR}, as many
bsd.lib.mk makefiles currently do.  We can now drop these or similar
lines (see libbz2/Makefile for example), but I think they are still
useful in at least developer mode.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age



msg38365/pgp0.pgp
Description: PGP signature


Re: make includes

2002-05-15 Thread Jeremy Lea

Hi,

On Tue, May 14, 2002 at 06:05:27PM +0300, Ruslan Ermilov wrote:
 On Wed, May 15, 2002 at 12:18:04AM +1000, Bruce Evans wrote:
  That's rather hackish, and doesn't handle garbage other than includes.
  I usually find stale files by comparing my world with a world installed
  in a nonstandard DESTDIR.  A mergemaster-like utility could automate
  this.
  
 Yes, I do this the same way actually.  :-)

For once I'd have to disagree with Bruce about the right way to do this. 
The right way is to have a packaging list, and to be able to pkg_upgrade
from /usr/src, which would do an orderly removal of all of the files
installed by an old world...  Then we can start work on spliting the
world into seperate packages.  We could even automate the generation of
the packaging list because we know everything in /usr/src is installed
by an install target somewhere in bsd.*.mk.

To answer the obvious questions: No, this is not possible at the moment. 
Yes, it is fairly easy to achieve.

Regards,
  -Jeremy

-- 
FreeBSD - Because the best things in life are free...
   http://www.freebsd.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: make includes

2002-05-15 Thread John Baldwin


On 15-May-2002 Bruce Evans wrote:
 On Tue, 14 May 2002, David O'Brien wrote:
 
 On Wed, May 15, 2002 at 12:38:49PM +1000, Bruce Evans wrote:
   I really do not like this change, please return things such that the
   long-ingraned cd /usr/src ; make includes.
 
  I planned to fix this by changing make includes to print
  Unwarranted chumminess with implementation.

 What is your perfered way to get the results of
 (cd /usr/src ; make includes) ?
 
 I prefer not to do this.  There are simpler methods to get broken
 headers, starting with rm -rf :).  I prefer everyone to use (documented)
 user-level targets like world and install for installing includes,
 since it would be difficult to make the includes target safe for general
 use.  I don't know what it really useful for.

It's useful for a new arch that doesn't have make world yet.  When I would
update world on my sparc before gcc was bmake'd it went something like this:

 sudo make includes
 sudo make libraries
 make obj  make depend  make
 sudo make install

To build and install a new world.

-- 

John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve!  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: make includes

2002-05-15 Thread Ruslan Ermilov

On Wed, May 15, 2002 at 09:26:29AM -0700, David O'Brien wrote:
 Almost correct.  For the record and future ports:
 
  It's useful for a new arch that doesn't have make world yet.  When I would
  update world on my sparc before gcc was bmake'd it went something like this:
 
 sudo make hierarchy
 
   sudo make includes
   sudo make libraries
   make obj  make depend  make
   sudo make install
  
  To build and install a new world.
 
With this simple patch,

%%%
--- Makefile.inc1~  Wed May 15 19:35:00 2002
+++ Makefile.inc1   Wed May 15 19:38:02 2002
@@ -330,6 +330,12 @@
 .endif
 WMAKE_TGTS+=   _includes _libraries _depend everything
 
+.for __target in ${WMAKE_TGTS}
+.if defined(NO${__target})
+WMAKE_TGTS:=   ${WMAKE_TGTS:N${__target}}
+.endif
+.endfor
+
 buildworld: ${WMAKE_TGTS}
 .ORDER: ${WMAKE_TGTS}
 
%%%

one can easily ``make buildworld TARGET_ARCH=foo -DNO_cross-tools''.
See the ``make -f Makefile.inc1 -V WMAKE_TGTS -DNO_cross-tools''
output for details.  (Yet one simple patch might be required to
exclude gnu/usr.bin/cc/cc_tools from the list of build-tools.)

Please let me know if you want me to commit this, or something
like that.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age



msg38380/pgp0.pgp
Description: PGP signature


Re: make includes

2002-05-15 Thread Bruce Evans

On Wed, 15 May 2002, David O'Brien wrote:

 Almost correct.  For the record and future ports:

[jhb wrote]
  It's useful for a new arch that doesn't have make world yet.  When I would
  update world on my sparc before gcc was bmake'd it went something like this:

 sudo make hierarchy

   sudo make includes
   sudo make libraries

What John wants is really these 2 steps.  Includes and libraries form a
usable subsset of the world, so it would be reasonable to have an end-user
target for it.  Hwowever, building that target robustly would involve a
lot more than the above.  All the tools for building the libraries would
have to be built, and that wouldn't work in this case.

   make obj  make depend  make
   sudo make install
 
  To build and install a new world.

Several other steps are missing.  Mainly make obj before make
libraries.  make obj is now necessary before make includes.

Bruce


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: make includes

2002-05-15 Thread David O'Brien

On Wed, May 15, 2002 at 07:43:22PM +0300, Ruslan Ermilov wrote:
 one can easily ``make buildworld TARGET_ARCH=foo -DNO_cross-tools''.

I am now doing many cross buildworlds.  Is there a target (used with
-DNOCLEAN) to use to save time and resume a build at stage 4?

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Skipping certain buildworld stages (was: Re: make includes)

2002-05-15 Thread Ruslan Ermilov

On Wed, May 15, 2002 at 03:18:15PM -0700, David O'Brien wrote:
 On Wed, May 15, 2002 at 07:43:22PM +0300, Ruslan Ermilov wrote:
  one can easily ``make buildworld TARGET_ARCH=foo -DNO_cross-tools''.
 
 I am now doing many cross buildworlds.  Is there a target (used with
 -DNOCLEAN) to use to save time and resume a build at stage 4?
 
With the patch I posted yesterday,

%%%
Index: Makefile.inc1
===
RCS file: /home/ncvs/src/Makefile.inc1,v
retrieving revision 1.277
diff -u -r1.277 Makefile.inc1
--- Makefile.inc1   15 May 2002 16:29:44 -  1.277
+++ Makefile.inc1   16 May 2002 06:06:09 -
@@ -330,6 +330,12 @@
 .endif
 WMAKE_TGTS+=   _includes _libraries _depend everything
 
+.for __target in ${WMAKE_TGTS}
+.if defined(NO${__target})
+WMAKE_TGTS:=   ${WMAKE_TGTS:N${__target}}
+.endif
+.endfor
+
 buildworld: ${WMAKE_TGTS}
 .ORDER: ${WMAKE_TGTS}
 
%%%

it's possible to achieve this with:

: make \
: -DNO_worldtmp -DNO_bootstrap-tools -DNO_cleanobj -DNO_obj \
: -DNO_build-tools -DNO_cross-tools \
: buildworld TARGET_ARCH=foo

Which in essence is equivalent to this sh(1) script:

: cd /whatever/usr/src
: for target in _includes _libraries _depend everything; do
:   make -m `pwd`/share/mk -f Makefile.inc1 \
:   ${target} TARGET_ARCH=foo
: done


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age



msg38416/pgp0.pgp
Description: PGP signature


Re: make includes

2002-05-14 Thread Ruslan Ermilov

[CC: to -current as others may benefit from it too]

On Mon, May 13, 2002 at 08:33:31PM +0200, Anders Andersson wrote:
 Hi,
 
 I write to you since you have been touching src/Makefile alot and so on.
 
 I sometimes want a fresh /usr/include and wipes it and does a:
 
 cd /usr/src  make includes
 
 but that does not work anymore!
 
 It seems that it does the correct thing but not a single file is
 installed in /usr/include
 
 Do you have any clue whats going on?
 
Yes.  make includes has been modified to mean build includes,
and the new make incsinstall has been added to install them.
So the correct sequence is make includes incsinstall.

I'm still unsure about the name; I'd have liked to rename it to
includesinstall but that is too long.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age



msg38306/pgp0.pgp
Description: PGP signature


Re: make includes

2002-05-14 Thread Riccardo Torrini

On 14-May-2002 (06:21:18/GMT) Ruslan Ermilov wrote:

 I'm still unsure about the name; I'd have liked to rename it to
 includesinstall but that is too long.

U, buildworld, installworld, buildkernel, installkernel...
It would be: buildinclude{s}, installinclude{s} just to be simmetric  :)
And is only one (or two) character longer than installkernel...


my .02 EUR
Riccardo.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: make includes

2002-05-14 Thread Ruslan Ermilov

On Tue, May 14, 2002 at 08:45:59AM +0200, Riccardo Torrini wrote:
 On 14-May-2002 (06:21:18/GMT) Ruslan Ermilov wrote:
 
  I'm still unsure about the name; I'd have liked to rename it to
  includesinstall but that is too long.
 
 U, buildworld, installworld, buildkernel, installkernel...
 It would be: buildinclude{s}, installinclude{s} just to be simmetric  :)
 And is only one (or two) character longer than installkernel...
 
Then all should similarly be renamed to build.  I like the idea
of consistent naming.  It's a pity we don't have synonyms in make(1).

build: buildprogram buildscripts buildfiles buildmanpages buildincludes
Then s/build/install/g.

build should probably be left as all for compatibility, I'm not sure.
Then we could say that we reserve target names all.* and install.*,
to avoid possible clashes.

I will see if I can implement something like that in a long term.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age



msg38309/pgp0.pgp
Description: PGP signature


Re: make includes

2002-05-14 Thread Bruce Evans

On Tue, 14 May 2002, Ruslan Ermilov wrote:

 Yes.  make includes has been modified to mean build includes,
 and the new make incsinstall has been added to install them.
 So the correct sequence is make includes incsinstall.

 I'm still unsure about the name; I'd have liked to rename it to
 includesinstall but that is too long.

I still prefer something like
__private_part_of_installworld_to_install_headers_dont_use_directly.

Bruce


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: make includes

2002-05-14 Thread Ruslan Ermilov

On Tue, May 14, 2002 at 06:21:41PM +1000, Bruce Evans wrote:
 On Tue, 14 May 2002, Ruslan Ermilov wrote:
 
  Yes.  make includes has been modified to mean build includes,
  and the new make incsinstall has been added to install them.
  So the correct sequence is make includes incsinstall.
 
  I'm still unsure about the name; I'd have liked to rename it to
  includesinstall but that is too long.
 
 I still prefer something like
 __private_part_of_installworld_to_install_headers_dont_use_directly.
 
EPARSE; what does that mean?  :-)

incsinstall is the standard target which performs a part of a normal
install -- installs C includes.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age



msg38321/pgp0.pgp
Description: PGP signature


Re: make includes

2002-05-14 Thread Anders Andersson

On Tue, May 14, 2002 at 09:21:18AM +0300, Ruslan Ermilov wrote:
 Yes.  make includes has been modified to mean build includes,
 and the new make incsinstall has been added to install them.
 So the correct sequence is make includes incsinstall.
 
 I'm still unsure about the name; I'd have liked to rename it to
 includesinstall but that is too long.

Why change in the first place?

What was wrong with 'make includes'? Why break POLA?
-- 
Anders Andersson[EMAIL PROTECTED]
Sanyusan Int. ABhttp://www.sanyusan.se/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: make includes

2002-05-14 Thread Ruslan Ermilov

On Tue, May 14, 2002 at 03:01:28PM +0200, Anders Andersson wrote:
 On Tue, May 14, 2002 at 09:21:18AM +0300, Ruslan Ermilov wrote:
  Yes.  make includes has been modified to mean build includes,
  and the new make incsinstall has been added to install them.
  So the correct sequence is make includes incsinstall.
  
  I'm still unsure about the name; I'd have liked to rename it to
  includesinstall but that is too long.
 
 Why change in the first place?
 
 What was wrong with 'make includes'? Why break POLA?
 
They were broken.  See commit log for share/mk/bsd.incs.mk,v 1.1 for
a full story.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age



msg38329/pgp0.pgp
Description: PGP signature


Re: make includes

2002-05-14 Thread Bruce Evans

On Tue, 14 May 2002, Ruslan Ermilov wrote:

 On Tue, May 14, 2002 at 06:21:41PM +1000, Bruce Evans wrote:
  On Tue, 14 May 2002, Ruslan Ermilov wrote:
 
   Yes.  make includes has been modified to mean build includes,
   and the new make incsinstall has been added to install them.
   So the correct sequence is make includes incsinstall.
  
   I'm still unsure about the name; I'd have liked to rename it to
   includesinstall but that is too long.
 
  I still prefer something like
  __private_part_of_installworld_to_install_headers_dont_use_directly.
 
 EPARSE; what does that mean?  :-)

 incsinstall is the standard target which performs a part of a normal
 install -- installs C includes.

Installing includes just corrupts the host environment unless the new
includes are consistent with the old libraries.  If you know the build
system, the includes and the libraries well enough to know when it is
safe to use, then you know enough to never need it.

Bruce


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: make includes

2002-05-14 Thread Ruslan Ermilov

On Tue, May 14, 2002 at 11:32:19PM +1000, Bruce Evans wrote:
 On Tue, 14 May 2002, Ruslan Ermilov wrote:
 
  On Tue, May 14, 2002 at 06:21:41PM +1000, Bruce Evans wrote:
   On Tue, 14 May 2002, Ruslan Ermilov wrote:
  
Yes.  make includes has been modified to mean build includes,
and the new make incsinstall has been added to install them.
So the correct sequence is make includes incsinstall.
   
I'm still unsure about the name; I'd have liked to rename it to
includesinstall but that is too long.
  
   I still prefer something like
   __private_part_of_installworld_to_install_headers_dont_use_directly.
  
  EPARSE; what does that mean?  :-)
 
  incsinstall is the standard target which performs a part of a normal
  install -- installs C includes.
 
 Installing includes just corrupts the host environment unless the new
 includes are consistent with the old libraries.  If you know the build
 system, the includes and the libraries well enough to know when it is
 safe to use, then you know enough to never need it.
 
People might want to use it like that:

make world
mv /usr/include /usr/include.old
make incsinstall

To remove stale includes.  Previous version had includes that both
built and installed includes, I have just split it in two parts.

(I will add the par-includes to Makefile.inc1 tomorrow, FWIW.)


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age



msg38336/pgp0.pgp
Description: PGP signature


Re: make includes

2002-05-14 Thread Sheldon Hearn



On Tue, 14 May 2002 16:34:56 +0300, Ruslan Ermilov wrote:

 People might want to use it like that:
 
 make world
 mv /usr/include /usr/include.old
 make incsinstall
 
 To remove stale includes.  Previous version had includes that both
 built and installed includes, I have just split it in two parts.

Pity we lost CLOBBER, which took care of this for you.

Ciao,
Sheldon.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: make includes

2002-05-14 Thread Bruce Evans

On Tue, 14 May 2002, Ruslan Ermilov wrote:

 On Tue, May 14, 2002 at 11:32:19PM +1000, Bruce Evans wrote:
  Installing includes just corrupts the host environment unless the new
  includes are consistent with the old libraries.  If you know the build
  system, the includes and the libraries well enough to know when it is
  safe to use, then you know enough to never need it.
 
 People might want to use it like that:

 make world
 mv /usr/include /usr/include.old
 make incsinstall

 To remove stale includes.  Previous version had includes that both
 built and installed includes, I have just split it in two parts.

That's rather hackish, and doesn't handle garbage other than includes.
I usually find stale files by comparing my world with a world installed
in a nonstandard DESTDIR.  A mergemaster-like utility could automate
this.

Bruce


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: make includes

2002-05-14 Thread Ruslan Ermilov

On Wed, May 15, 2002 at 12:18:04AM +1000, Bruce Evans wrote:
 On Tue, 14 May 2002, Ruslan Ermilov wrote:
 
  On Tue, May 14, 2002 at 11:32:19PM +1000, Bruce Evans wrote:
   Installing includes just corrupts the host environment unless the new
   includes are consistent with the old libraries.  If you know the build
   system, the includes and the libraries well enough to know when it is
   safe to use, then you know enough to never need it.
  
  People might want to use it like that:
 
  make world
  mv /usr/include /usr/include.old
  make incsinstall
 
  To remove stale includes.  Previous version had includes that both
  built and installed includes, I have just split it in two parts.
 
 That's rather hackish, and doesn't handle garbage other than includes.
 I usually find stale files by comparing my world with a world installed
 in a nonstandard DESTDIR.  A mergemaster-like utility could automate
 this.
 
Yes, I do this the same way actually.  :-)


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age



msg38339/pgp0.pgp
Description: PGP signature


Re: make includes

2002-05-14 Thread David O'Brien

On Tue, May 14, 2002 at 09:21:18AM +0300, Ruslan Ermilov wrote:
 
 Yes.  make includes has been modified to mean build includes,
 and the new make incsinstall has been added to install them.
 So the correct sequence is make includes incsinstall.


I really do not like this change, please return things such that the
long-ingraned cd /usr/src ; make includes.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: make includes

2002-05-14 Thread David O'Brien

On Tue, May 14, 2002 at 04:10:51PM +0300, Ruslan Ermilov wrote:
  Why change in the first place?
  
  What was wrong with 'make includes'? Why break POLA?
  
 They were broken.  See commit log for share/mk/bsd.incs.mk,v 1.1 for
 a full story.

I fail to see how they were broken from the rev 1.1 bsd.incs.mk log.
It looks like you just hyjacked the `includes' target.  Why could you not
have used `incbuild' and `incinstall'?  Then includes is something like

includes: incbuild incinstall

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: make includes

2002-05-14 Thread Hiten Pandya

--- Ruslan Ermilov [EMAIL PROTECTED] wrote:
 People might want to use it like that:
 
 make world
 mv /usr/include /usr/include.old

Sorry to butt in; but wouldn't it be more good if this step was done
by the build scripts itself? (refering to: mv /usr/include /usr/include.old)

 make incsinstall

Regards.

-- 
Hiten Pandya
Finger [EMAIL PROTECTED] for PGP Public Key
See complete mail headers for address information
WWW: http://storm.uk.FreeBSD.org/~hiten/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: make includes

2002-05-14 Thread Bruce Evans

On Tue, 14 May 2002, David O'Brien wrote:

 On Tue, May 14, 2002 at 09:21:18AM +0300, Ruslan Ermilov wrote:
 
  Yes.  make includes has been modified to mean build includes,
  and the new make incsinstall has been added to install them.
  So the correct sequence is make includes incsinstall.

 I really do not like this change, please return things such that the
 long-ingraned cd /usr/src ; make includes.

I planned to fix this by changing make includes to print
Unwarranted chumminess with implementation.

Bruce


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: make includes

2002-05-14 Thread David O'Brien

On Wed, May 15, 2002 at 12:38:49PM +1000, Bruce Evans wrote:
  I really do not like this change, please return things such that the
  long-ingraned cd /usr/src ; make includes.
 
 I planned to fix this by changing make includes to print
 Unwarranted chumminess with implementation.

What is your perfered way to get the results of
(cd /usr/src ; make includes) ?

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: 'make includes' ownership patch

2001-05-29 Thread Bruce Evans

On Mon, 28 May 2001, Kris Kennaway wrote:

 On Mon, May 28, 2001 at 10:31:58AM -0700, Rodney W. Grimes wrote:
   [Someone wrote]
   What was the reasoning for a serperate owner specification from BIN*?
  
  Simple orthagonality.  Ie, each bsd.*.mk file typically has a seperate
  set of *{DIR/OWN/GRP/MODE} specs.  bsd.inc.mk was cloned from another
  bsd.*.mk file.
 
 Well, I don't mind how it gets fixed, but it's very unorthogonal at
 the moment having to set two sets of OWN/GRP variables in order to
 make includes as non-root.

This shouldn't be a problem, because includes is an undocumented private
target in src/Makefile.inc1.  Running it independently of buildworld
is usually wrong.  You would have to set the two sets to run buildworld.
You would also have to set the other set that doesn't default to the BIN
set, i.e., the SHARE set.  To set all the sets to different values, you
would also have to set the following sets:

KMOD, LIB (these mostly default to the BIN set)
DOC, INFO, MAN, NLS (these mostly default to the SHARE set)

There is a little too much orthogonality here.

Bruce


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: 'make includes' ownership patch

2001-05-28 Thread Ruslan Ermilov

On Sat, May 26, 2001 at 03:06:00PM -0700, Kris Kennaway wrote:
 On Sat, May 26, 2001 at 02:59:22PM -0700, Kris Kennaway wrote:
  Shouldn't the includes/Makefile be installing headers using
  INCOWN/INCGRP instead of BINOWN/BINGRP?  I ran into this when trying
  to do a 'make includes' as a normal user.
 
 Oops, hit send too soon; more changes are required of the same form.
 Before I go to the trouble of doing those, I might as well get
 confirmation whether this is the right thing to do.
 
This was on my TODO.  The only problem with INCOWN/INCGRP not being
used here is that they were introduced long after include/Makefile.


Cheers,
-- 
Ruslan Ermilov  Oracle Developer/DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: 'make includes' ownership patch

2001-05-28 Thread Rodney W. Grimes

 On Sat, May 26, 2001 at 03:06:00PM -0700, Kris Kennaway wrote:
  On Sat, May 26, 2001 at 02:59:22PM -0700, Kris Kennaway wrote:
   Shouldn't the includes/Makefile be installing headers using
   INCOWN/INCGRP instead of BINOWN/BINGRP?  I ran into this when trying
   to do a 'make includes' as a normal user.
  
  Oops, hit send too soon; more changes are required of the same form.
  Before I go to the trouble of doing those, I might as well get
  confirmation whether this is the right thing to do.
  
 This was on my TODO.  The only problem with INCOWN/INCGRP not being
 used here is that they were introduced long after include/Makefile.

And perhaps one should go read the commit message that introduced them...
it was an experiment, a sample test designed to only be used in -current
/usr/src/lib, that BDE, Sheldon and myself had long followon conversations
about, and got dropped into the cracks.

The name INC* is not clear as to be correct, per BDE it probably should be
HDR* or HDRS* (I specifically avoided that since existing Makefiles used
that, not knowing that BDE had seperately been eyeing HDRS* for what I
ended up calling INC*.)

Since, other commiters have ignored direct, and inderect requests not to
propogate this INC* experiment, and it now infects all the way back to
at least 3.x* and possibly 4.*, making it near impossible to clean up :-(.

So feel free to ignore this email and change src/include/Makefile any
way you wish...

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: 'make includes' ownership patch

2001-05-28 Thread David O'Brien

On Mon, May 28, 2001 at 10:22:33AM -0700, Rodney W. Grimes wrote:
  This was on my TODO.  The only problem with INCOWN/INCGRP not being
  used here is that they were introduced long after include/Makefile.
 
 And perhaps one should go read the commit message that introduced them...
 it was an experiment, a sample test designed to only be used in -current
 /usr/src/lib, that BDE, Sheldon and myself had long followon conversations
 about, and got dropped into the cracks.

What was the reasoning for a serperate owner specification from BIN*?

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: 'make includes' ownership patch

2001-05-28 Thread Ruslan Ermilov

On Mon, May 28, 2001 at 10:26:11AM -0700, David O'Brien wrote:
 On Mon, May 28, 2001 at 10:22:33AM -0700, Rodney W. Grimes wrote:
   This was on my TODO.  The only problem with INCOWN/INCGRP not being
   used here is that they were introduced long after include/Makefile.
  
  And perhaps one should go read the commit message that introduced them...
  it was an experiment, a sample test designed to only be used in -current
  /usr/src/lib, that BDE, Sheldon and myself had long followon conversations
  about, and got dropped into the cracks.
 
 What was the reasoning for a serperate owner specification from BIN*?
 
Because headers are installed with NOBINMODE, not BINMODE :-)


Cheers,
-- 
Ruslan Ermilov  Oracle Developer/DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: 'make includes' ownership patch

2001-05-28 Thread Kris Kennaway

On Mon, May 28, 2001 at 10:31:58AM -0700, Rodney W. Grimes wrote:
  On Mon, May 28, 2001 at 10:22:33AM -0700, Rodney W. Grimes wrote:
This was on my TODO.  The only problem with INCOWN/INCGRP not being
used here is that they were introduced long after include/Makefile.
   
   And perhaps one should go read the commit message that introduced them...
   it was an experiment, a sample test designed to only be used in -current
   /usr/src/lib, that BDE, Sheldon and myself had long followon conversations
   about, and got dropped into the cracks.
  
  What was the reasoning for a serperate owner specification from BIN*?
 
 Simple orthagonality.  Ie, each bsd.*.mk file typically has a seperate
 set of *{DIR/OWN/GRP/MODE} specs.  bsd.inc.mk was cloned from another
 bsd.*.mk file.

Well, I don't mind how it gets fixed, but it's very unorthogonal at
the moment having to set two sets of OWN/GRP variables in order to
make includes as non-root.

Someone tell me what they should be using and I'll fix it.

Kris

 PGP signature


Re: 'make includes' ownership patch

2001-05-28 Thread Rodney W. Grimes

 On Mon, May 28, 2001 at 10:31:58AM -0700, Rodney W. Grimes wrote:
   On Mon, May 28, 2001 at 10:22:33AM -0700, Rodney W. Grimes wrote:
 This was on my TODO.  The only problem with INCOWN/INCGRP not being
 used here is that they were introduced long after include/Makefile.

And perhaps one should go read the commit message that introduced them...
it was an experiment, a sample test designed to only be used in -current
/usr/src/lib, that BDE, Sheldon and myself had long followon conversations
about, and got dropped into the cracks.
   
   What was the reasoning for a serperate owner specification from BIN*?
  
  Simple orthagonality.  Ie, each bsd.*.mk file typically has a seperate
  set of *{DIR/OWN/GRP/MODE} specs.  bsd.inc.mk was cloned from another
  bsd.*.mk file.
 
 Well, I don't mind how it gets fixed, but it's very unorthogonal at
 the moment having to set two sets of OWN/GRP variables in order to
 make includes as non-root.
 
 Someone tell me what they should be using and I'll fix it.

Change bsd.own.mk to:
INCOWN?=${BINOWN}
INCGRP?=${BINGRP}
INCMODE?=   ${NOBINMODE}

as a temporary hack until INC* and bsd.inc.mk is completed/gutted/replaced/
whatever.



-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: 'make includes' ownership patch

2001-05-26 Thread Kris Kennaway

On Sat, May 26, 2001 at 02:59:22PM -0700, Kris Kennaway wrote:
 Shouldn't the includes/Makefile be installing headers using
 INCOWN/INCGRP instead of BINOWN/BINGRP?  I ran into this when trying
 to do a 'make includes' as a normal user.

Oops, hit send too soon; more changes are required of the same form.
Before I go to the trouble of doing those, I might as well get
confirmation whether this is the right thing to do.

Kris


 PGP signature