Re: CVS commit: src

2017-02-17 Thread Kamil Rytarowski 
On 17.02.2017 22:47, Robert Elz wrote:
> Date:Fri, 17 Feb 2017 22:28:32 +0100
> From:Kamil Rytarowski 
> Message-ID:  <1f5043f2-b004-f558-bd66-cc96675ab...@gmx.com>
> 
> 
>   | Thank you for your feedback. I was required to manually remove old files
>   | in order to regenerate locally new siginfo.c..
> 
> That means you didn't do "make includes" first before building.   build.sh
> does.
> 

I see, I will use it in future. Thank you!

> For whatever reason, the siginfo.c file depends upon 
> ${DESTDIR}/usr/include/...
> rather than ../../src/sys/...  (perhaps in order to allow the same 
> Makefile.inc
> to be used from multiple places, I am not sure - the usual reason for this is
> to depend upon an arch or machine dependant .h file, which this is not.)
> 
> kre
> 




signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src

2017-02-17 Thread Robert Elz 
Date:Fri, 17 Feb 2017 22:28:32 +0100
From:Kamil Rytarowski 
Message-ID:  <1f5043f2-b004-f558-bd66-cc96675ab...@gmx.com>


  | Thank you for your feedback. I was required to manually remove old files
  | in order to regenerate locally new siginfo.c..

That means you didn't do "make includes" first before building.   build.sh
does.

For whatever reason, the siginfo.c file depends upon ${DESTDIR}/usr/include/...
rather than ../../src/sys/...  (perhaps in order to allow the same Makefile.inc
to be used from multiple places, I am not sure - the usual reason for this is
to depend upon an arch or machine dependant .h file, which this is not.)

kre

Re: CVS commit: src

2017-02-17 Thread Kamil Rytarowski 
On 17.02.2017 15:03, Robert Elz wrote:
> Date:Fri, 17 Feb 2017 01:42:59 +
> From:"Kamil Rytarowski" 
> Message-ID:  <20170217014259.e68fef...@cvs.netbsd.org>
> 
>   | Modified Files:
>   |   src: UPDATING
>   | 
>   | Log Message:
>   | Note TRAP_HWWPT -> TRAP_DBREG rename manual steps for build.sh -u
> 
> I think you can remove that entry from UPDATING.
> 
> It is bad enough that the build system cannot handle dealing with
> files that used to exist (but are no longer referenced anywhere in
> the Makefiles, or elsewhere) - but understandable - it is not easy
> to arrange to remove something whose name is unknown (though it could
> be done, at a cost) and some other (files changing type, etc) issues --
> but it would be a serious problem if a file that is supposed to exist
> failed to be regenerated when a file it depends upon has changed.
> Dealing with that is exactly what make and makefiles are all about.
> 
> I could see no reason why the relevant files in this case would not
> be correctly regenerated without manual intervention, so I did an
> update build without removing them manually (I had done a full build more
> recently than the 20170211 terminfo update - and while I did not look to
> see why that one required avoiding -u, it might be another that did not
> really require that), and sure enough, the build system worked properly,
> the siginfo.c iles were correctly regenerated as expected.
> 
> There is no need for any unusual manual intervention here.
> 
> kre
> 

Thank you for your feedback. I was required to manually remove old files
in order to regenerate locally new siginfo.c.. as I faced a build error.
I think it's not worth the effort to build the distribution twice to
reproduce it again, I will just remove it.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src

2017-02-17 Thread Robert Elz 
Date:Fri, 17 Feb 2017 01:42:59 +
From:"Kamil Rytarowski" 
Message-ID:  <20170217014259.e68fef...@cvs.netbsd.org>

  | Modified Files:
  | src: UPDATING
  | 
  | Log Message:
  | Note TRAP_HWWPT -> TRAP_DBREG rename manual steps for build.sh -u

I think you can remove that entry from UPDATING.

It is bad enough that the build system cannot handle dealing with
files that used to exist (but are no longer referenced anywhere in
the Makefiles, or elsewhere) - but understandable - it is not easy
to arrange to remove something whose name is unknown (though it could
be done, at a cost) and some other (files changing type, etc) issues --
but it would be a serious problem if a file that is supposed to exist
failed to be regenerated when a file it depends upon has changed.
Dealing with that is exactly what make and makefiles are all about.

I could see no reason why the relevant files in this case would not
be correctly regenerated without manual intervention, so I did an
update build without removing them manually (I had done a full build more
recently than the 20170211 terminfo update - and while I did not look to
see why that one required avoiding -u, it might be another that did not
really require that), and sure enough, the build system worked properly,
the siginfo.c iles were correctly regenerated as expected.

There is no need for any unusual manual intervention here.

kre