Re: CVS commit: src/usr.bin/make
Simon J. Gerraty wrote: > Joerg Sonnenberger wrote: > > Build log and content of the build directory can be found in > > http://www.netbsd.org/~joerg/xemacs-21.5.27nb22.tar.gz > > Hmm, the makefile clears suffixes, but does not provide > a single suffix rule for .c lib-src/Makefile.in.in implies they do not want to rely on any builtin/prexisting rules: ## For performance and consistency, no built-in rules .SUFFIXES: .SUFFIXES: .c .h .o ## They should provide an explict rule or at least a single suffix rule. Which - they do: #ifndef DUMP_IN_EXEC insert-data-in-exec: ${srcdir}/insert-data-in-exec.c $(CC) $(cflags) ${srcdir}/insert-data-in-exec.c $(ldflags) -o $@ #endif /* not DUMP_IN_EXEC */ It is also there in Makefile.in but not in Makefile So, not a bug in make - but in how we get from lib-src/Makefile.in* to Makefile
Re: CVS commit: src/usr.bin/make
Joerg Sonnenberger wrote: > Build log and content of the build directory can be found in > http://www.netbsd.org/~joerg/xemacs-21.5.27nb22.tar.gz Hmm, the makefile clears suffixes, but does not provide a single suffix rule for .c
Re: CVS commit: src/usr.bin/make
On Sat, Jan 16, 2016 at 04:15:21PM -0800, Simon J. Gerraty wrote: > Joerg Sonnenberger wrote: > > I suspect this change broke editors/xemacs-current, which is now failing > > with: > > > > make[1]: make[1]: don't know how to make insert-data-in-exec. Stop > > I'm guessing you are talking about a makefile that comes with emacs? > I don't see anything in editors/xemacs-current itself. > Do you happen to have an accessible machine with the makefile(s) in > question? Build log and content of the build directory can be found in http://www.netbsd.org/~joerg/xemacs-21.5.27nb22.tar.gz Joerg
Re: CVS import: othersrc/external/mit/micropython
Taken from othersrc/README: "The "othersrc" collection consists of programs that are either "not ready for the main tree" or "never going to be ready for the main tree" but which are NOT appropriate to pkgsrc because they have no external maintainer." In this case, it's a case of not quite ready for the main tree - I've been looking for a small, embeddable python for a long time (cpython doesn't quite hit those checklist items), and micropython fits the bill. I found that tinypy (http://www.philhassey.com/blog/wp-content/uploads/2008/02/tinypy.tgz) was too difficult to modify, and was fairly long in the tooth these days. Micropython, OTOH, is a 3.4 clone, which works well for me. The problem, as ever, is in libffi - then there is library function support, and, after that, module support, but I think this is a step in the right direction. I talked briefly to christos about micropython, and he encouraged me to take it to tech-misc, and I shall try to do that, but I'm behind on so much mail right now, it's embarassing. My goal is to have micropython be next to lua in the toolchain, not in place of it (although I think there's going to come a time quite soon where lua is going to have to justify its existence, and not just the netpgp bindings I wrote, as I also did perl, python and tcl bindings at the same time). Definitely not aiming to be a fork - the external sources were imported on a vendor branch, and local fixes for reachover infrastructure and NetBSD packaging were added afterwards so that we can incorporate future updates from upstream. I have a pkgsrc entry made for it micropython-1.5.2, will try to add it RSN. Best, Alistair On 16 January 2016 at 05:42, Kamil Rytarowski wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 14.01.2016 02:38, Alistair G. Crooks wrote: >> Module Name: othersrc Committed By: agc Date: Thu Jan 14 >> 01:38:53 >> UTC 2016 >> >> Update of /cvsroot/othersrc/external/mit/micropython In directory >> ivanova.netbsd.org:/tmp/cvs-serv18307 >> >> Log Message: Import micropython version 1.5.2 into othersrc. >> >> Micropython is a python3 implementation that has been optimised >> for micro-controllers and small embedded systems. It also has a >> "unix" port. It has an MIT license. >> > > Does it mean that it's prepared to be used as an extra set (located in > othersrc/) of sources in the NetBSD base? > > Is it going to be evaluated for inclusion to base (next to Lua)? > > Is aimed to be a fork? > > Why not in pkgsrc? > > Thanks for making it clear. > -BEGIN PGP SIGNATURE- > Version: GnuPG v2 > > iQIcBAEBCAAGBQJWmkjbAAoJEEuzCOmwLnZsF3gP/RN9BpGOMNkTk7veDcEEXSxE > D+KJFOtRmg+lyocuK8heDt3KbKO6UaLBc1n30DMKYZ/u1wcm6es2XEe6kmqTcQLf > KZ3WH1QQwfpQpcuq/T9Lvo9ZZQwn0ui4ZGEERARadsJOPYL5IFOczVvJFJGgMlNT > qWfSYxHYbKnxa9Ftn0oGsKHJPmsCUxvgKIpCKC3hUl8gbYw9H5wCyk8w0ZVWaor9 > fmqiNxbU6Mq4p3agNS3TLa/ISmetal8RqPFXsLIslUTA1dfDwP/xjxaZYBZEB54V > Is9M1JxVnM7cOUAjmd5e/0fuxPMl3XA69lofBNkESdh/jYFGd+lEn59slfRSmlT/ > e8DKyWECS7dyjx2ne1XdUPrZ3tgwIGQmaYfAi7cqaabOQIaxh3e08Blo4LE+s1zU > +3KZuojj5Z/jkYdK27E7XuROMslIuVIIYHWr8xjV08Pc1zoLbQXzm+VITtJltKWi > 4c4VjjE2uTEfaP8N3MDG7JlyUBa8snAoJU1XDjdetoXW2cE3OOEpYJREGfjreT6i > J+VlU+7Beu0VbJwnGBd7lkoZzdkC84Ph9nop190iMsuUKmXLvFMHgdkVsWhm9Hu6 > aGaTimrxBXGQYNosqxZgy4dOJU0aHFD/T/XCr623UsQY/pQ3TDfDe1V+6kBmm/7o > woGjrYDz+QkVMe1HEvUp > =lik+ > -END PGP SIGNATURE- >
Re: CVS commit: src/usr.bin/make
Joerg Sonnenberger wrote: > I suspect this change broke editors/xemacs-current, which is now failing > with: > > make[1]: make[1]: don't know how to make insert-data-in-exec. Stop I'm guessing you are talking about a makefile that comes with emacs? I don't see anything in editors/xemacs-current itself. Do you happen to have an accessible machine with the makefile(s) in question?
Re: CVS commit: src/usr.bin/make
On Sun, Dec 20, 2015 at 10:44:10PM +, Simon J. Gerraty wrote: > Module Name: src > Committed By: sjg > Date: Sun Dec 20 22:44:10 UTC 2015 > > Modified Files: > src/usr.bin/make: suff.c > > Log Message: > Suff_ClearSuffixes() needs to re-initialize suffNull, > otherwise its children retain old suffixes. > Have Suff_Init() call Suff_ClearSuffixes() for consistency. I suspect this change broke editors/xemacs-current, which is now failing with: make[1]: make[1]: don't know how to make insert-data-in-exec. Stop Joerg
Re: CVS import: othersrc/external/mit/micropython
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 14.01.2016 02:38, Alistair G. Crooks wrote: > Module Name: othersrc Committed By: agc Date: Thu Jan 14 > 01:38:53 > UTC 2016 > > Update of /cvsroot/othersrc/external/mit/micropython In directory > ivanova.netbsd.org:/tmp/cvs-serv18307 > > Log Message: Import micropython version 1.5.2 into othersrc. > > Micropython is a python3 implementation that has been optimised > for micro-controllers and small embedded systems. It also has a > "unix" port. It has an MIT license. > Does it mean that it's prepared to be used as an extra set (located in othersrc/) of sources in the NetBSD base? Is it going to be evaluated for inclusion to base (next to Lua)? Is aimed to be a fork? Why not in pkgsrc? Thanks for making it clear. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWmkjbAAoJEEuzCOmwLnZsF3gP/RN9BpGOMNkTk7veDcEEXSxE D+KJFOtRmg+lyocuK8heDt3KbKO6UaLBc1n30DMKYZ/u1wcm6es2XEe6kmqTcQLf KZ3WH1QQwfpQpcuq/T9Lvo9ZZQwn0ui4ZGEERARadsJOPYL5IFOczVvJFJGgMlNT qWfSYxHYbKnxa9Ftn0oGsKHJPmsCUxvgKIpCKC3hUl8gbYw9H5wCyk8w0ZVWaor9 fmqiNxbU6Mq4p3agNS3TLa/ISmetal8RqPFXsLIslUTA1dfDwP/xjxaZYBZEB54V Is9M1JxVnM7cOUAjmd5e/0fuxPMl3XA69lofBNkESdh/jYFGd+lEn59slfRSmlT/ e8DKyWECS7dyjx2ne1XdUPrZ3tgwIGQmaYfAi7cqaabOQIaxh3e08Blo4LE+s1zU +3KZuojj5Z/jkYdK27E7XuROMslIuVIIYHWr8xjV08Pc1zoLbQXzm+VITtJltKWi 4c4VjjE2uTEfaP8N3MDG7JlyUBa8snAoJU1XDjdetoXW2cE3OOEpYJREGfjreT6i J+VlU+7Beu0VbJwnGBd7lkoZzdkC84Ph9nop190iMsuUKmXLvFMHgdkVsWhm9Hu6 aGaTimrxBXGQYNosqxZgy4dOJU0aHFD/T/XCr623UsQY/pQ3TDfDe1V+6kBmm/7o woGjrYDz+QkVMe1HEvUp =lik+ -END PGP SIGNATURE-