Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #172151 > unrolled thread
| Started by | Bart <bc@freeuk.com> |
|---|---|
| First post | 2023-08-13 14:53 +0100 |
| Last post | 2023-08-29 04:43 -0700 |
| Articles | 20 on this page of 306 — 31 participants |
Back to article view | Back to comp.lang.c
Build Systems Bart <bc@freeuk.com> - 2023-08-13 14:53 +0100
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-13 21:45 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-13 23:43 +0100
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-14 01:16 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-14 00:46 +0000
Re: Build Systems gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-14 01:05 +0000
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-13 18:59 -0700
Dev on Windoze (Was: Build Systems) gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-14 02:44 +0000
Re: Dev on Windoze (Was: Build Systems) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-13 20:53 -0700
Re: Dev on Windoze (Was: Build Systems) Matthew Ernisse <matt@going-flying.com> - 2023-08-17 22:00 +0000
Re: Dev on Windoze (Was: Build Systems) Michael S <already5chosen@yahoo.com> - 2023-08-18 03:51 -0700
Re: Dev on Windoze (Was: Build Systems) bart c <bart4858@gmail.com> - 2023-08-18 04:58 -0700
Re: Dev on Windoze (Was: Build Systems) Matthew Ernisse <matt@going-flying.com> - 2023-08-18 13:02 +0000
Re: Dev on Windoze Phil Carmody <pc+usenet@asdf.org> - 2023-08-20 16:14 +0300
Re: Dev on Windoze "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-20 11:05 -0700
Re: Dev on Windoze (Was: Build Systems) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-18 16:16 -0700
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-14 04:03 +0000
Re: Build Systems gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-14 10:14 +0000
Re: Build Systems Karl Meyer <karlmeyer25@gmail.com> - 2023-08-14 05:16 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-14 10:35 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-14 15:06 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-14 14:58 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-14 15:49 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-14 18:00 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-15 11:00 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-15 11:40 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-15 15:21 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-15 16:11 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-15 15:39 +0000
Re: Build Systems MJ OS_EXAMINE <m6502x64@gmail.com> - 2023-08-15 08:58 -0700
Re: Build Systems gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-15 16:44 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-15 20:00 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-15 18:03 +0200
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-15 17:01 +0000
Re: Build Systems gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-15 17:07 +0000
Re: Build Systems Phil Carmody <pc+usenet@asdf.org> - 2023-08-15 23:17 +0300
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-15 22:57 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-15 18:49 +0100
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-15 13:13 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-15 23:09 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-15 23:36 +0100
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-15 15:55 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-16 01:05 +0100
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-16 01:39 +0000
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-16 11:37 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-16 12:15 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-16 15:16 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-16 16:34 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-16 18:07 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-16 17:43 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-16 18:51 +0100
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-16 21:26 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-16 22:25 +0100
Re: Build Systems Richard Harnden <richard.nospam@gmail.com> - 2023-08-17 00:15 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-17 01:02 +0100
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-17 02:56 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-17 11:21 +0100
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-17 21:26 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-17 23:40 +0100
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-19 00:43 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-17 15:45 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-18 00:24 +0100
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-17 17:46 -0700
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-17 18:29 -0700
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-17 19:13 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-18 14:55 +0200
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-18 14:34 -0700
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-18 14:34 -0700
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-18 15:19 -0700
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-18 15:43 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-19 13:19 +0200
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-26 20:56 -0700
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-26 20:57 -0700
Re: Build Systems "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-08-27 00:01 -0700
Re: Build Systems candycane@f172.n1.z21.fsxnet (candycane) - 2023-08-27 03:34 +1300
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-27 08:32 +0000
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-27 16:58 +0200
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-27 11:58 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-27 16:52 +0200
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-27 11:59 -0700
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-18 01:49 +0000
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-18 02:19 -0700
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-19 01:21 +0100
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-18 18:36 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-19 13:51 +0200
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-19 05:35 -0700
Re: Build Systems Kelsey Bjarnason <kbjarnason@gmail.com> - 2023-08-19 00:35 -0700
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-19 09:54 -0700
Re: Build Systems Kelsey Bjarnason <kbjarnason@gmail.com> - 2023-08-19 12:30 -0700
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-19 13:44 -0700
Re: Build Systems Kelsey Bjarnason <kbjarnason@gmail.com> - 2023-08-21 17:58 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-22 02:28 +0100
Re: Build Systems Kelsey Bjarnason <kbjarnason@gmail.com> - 2023-08-22 00:12 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-22 11:13 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-22 11:36 +0100
Re: Build Systems Richard Harnden <richard.nospam@gmail.com> - 2023-08-22 13:37 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-22 13:51 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-22 14:51 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-22 17:19 +0100
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-22 09:30 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-22 17:51 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-22 16:36 +0000
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-22 16:50 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-22 18:06 +0100
Re: Build Systems kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-08-22 20:46 +0000
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-22 12:47 -0700
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-26 21:06 -0700
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-22 17:04 +0000
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-20 00:10 +0100
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-19 17:50 -0700
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-20 20:48 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-20 22:07 +0100
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-21 00:51 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-21 01:26 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-21 02:02 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-21 02:07 +0100
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-21 03:13 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-21 11:09 +0100
Re: Build Systems Richard Harnden <richard.nospam@gmail.com> - 2023-08-21 13:12 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-21 14:12 +0100
Re: Build Systems Richard Harnden <richard.nospam@gmail.com> - 2023-08-21 14:47 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-21 19:06 +0100
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-21 18:40 +0000
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-21 14:39 -0700
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-21 12:23 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-21 21:55 +0100
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-22 01:31 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-22 02:18 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-22 14:41 +0000
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-22 08:03 -0700
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-22 15:33 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-22 16:20 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-22 15:40 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-22 17:03 +0100
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-23 03:18 +0100
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-22 19:51 -0700
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-25 02:23 +0100
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-24 21:24 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-25 11:31 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-25 10:53 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-25 13:55 +0200
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-25 13:54 +0000
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-25 20:55 +0100
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-25 20:49 -0700
Re: Build Systems Richard Harnden <richard.nospam@gmail.com> - 2023-08-23 08:42 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-23 11:37 +0100
Re: Build Systems Anton Shepelev <anton.txt@g{oogle}mail.com> - 2023-08-23 14:02 +0300
Re: Build Systems Richard Harnden <richard.nospam@gmail.com> - 2023-08-23 15:02 +0100
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-25 02:17 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-23 14:28 +0100
Re: Build Systems Anton Shepelev <anton.txt@g{oogle}mail.com> - 2023-08-23 19:54 +0300
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-23 19:33 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-23 21:13 +0100
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-23 23:09 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-24 15:32 +0200
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-24 15:51 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-24 18:58 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-24 18:29 +0000
Re: Build Systems vallor <vallor@cultnix.org> - 2023-08-24 20:41 +0000
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-24 23:08 +0000
Re: Build Systems Rainer Weikusat <rweikusat@talktalk.net> - 2023-08-25 17:22 +0100
Re: Build Systems Spiros Bousbouras <spibou@gmail.com> - 2023-08-25 16:39 +0000
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-25 16:54 +0000
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-25 17:02 +0000
Re: Build Systems Rainer Weikusat <rweikusat@talktalk.net> - 2023-08-25 19:21 +0100
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-25 18:56 +0000
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-24 11:44 -0700
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-24 18:47 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-24 21:20 +0100
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-24 22:59 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-25 02:18 +0100
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-24 20:17 -0700
Re: Build Systems Anton Shepelev <anton.txt@g{oogle}mail.com> - 2023-08-24 16:30 +0300
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-23 17:43 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-23 20:15 +0100
Re: Build Systems Anton Shepelev <anton.txt@gmail.moc> - 2023-08-26 18:19 +0300
Re: Build Systems Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-26 21:47 -0700
Re: Build Systems Anton Shepelev <anton.txt@g{oogle}mail.com> - 2023-08-28 11:31 +0300
Re: Build Systems Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-28 06:48 -0700
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-25 02:11 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-25 11:27 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-25 13:52 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-25 15:40 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-25 20:04 +0200
Re: Build Systems candycane@f172.n1.z21.fsxnet (candycane) - 2023-08-26 00:47 +1300
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-25 21:26 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-26 01:42 +0100
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-27 01:16 +0100
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-25 05:51 +0000
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-24 23:17 -0700
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-21 02:52 +0000
Re: Build Systems vallor <vallor@cultnix.org> - 2023-08-21 03:02 +0000
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-21 06:05 +0000
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-21 11:32 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-19 14:42 +0000
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-19 08:09 -0700
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-19 15:59 +0000
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-19 09:38 -0700
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-19 18:16 +0000
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-19 21:02 +0000
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-19 14:13 -0700
Re: Build Systems Ike Naar <ike@sdf.org> - 2023-08-19 19:10 +0000
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-19 21:00 +0000
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-19 14:22 -0700
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-19 17:56 -0700
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-19 18:13 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-20 14:13 +0200
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-20 06:05 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-20 16:15 +0200
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-20 09:25 -0700
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-20 13:35 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-21 14:43 +0200
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-21 05:52 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-21 14:30 +0100
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-21 15:18 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-21 23:26 +0100
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-21 16:11 -0700
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-21 14:47 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-21 23:20 +0100
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-21 15:45 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-22 00:57 +0100
Re: Build Systems vallor <vallor@cultnix.org> - 2023-08-20 14:24 +0000
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-20 09:09 -0700
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-20 17:28 +0000
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-19 20:26 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-18 14:50 +0200
Re: Build Systems Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2023-08-18 13:19 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-17 17:16 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-17 17:24 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-18 15:32 +0200
Re: Build Systems Michael S <already5chosen@yahoo.com> - 2023-08-18 07:22 -0700
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-18 07:48 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-18 17:11 +0200
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-18 08:58 -0700
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-18 16:32 -0700
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-20 04:02 -0700
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-22 12:26 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-19 13:56 +0200
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-19 05:43 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-16 11:23 +0200
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-16 02:34 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-16 12:52 +0200
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-16 03:56 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-16 13:23 +0200
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-16 12:55 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-17 15:52 +0200
Re: Build Systems Michael S <already5chosen@yahoo.com> - 2023-08-17 02:14 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-17 15:56 +0200
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-17 16:01 +0000
Re: Build Systems Michael S <already5chosen@yahoo.com> - 2023-08-17 09:07 -0700
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-17 16:20 +0000
Re: Build Systems Michael S <already5chosen@yahoo.com> - 2023-08-17 09:31 -0700
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-17 17:24 +0000
Re: Build Systems Phil Carmody <pc+usenet@asdf.org> - 2023-08-19 14:06 +0300
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-19 04:39 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-19 16:46 +0200
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-19 16:00 +0000
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-20 14:15 +0200
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-20 07:25 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-20 18:03 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-17 19:51 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-18 16:44 +0200
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-18 08:21 -0700
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-18 15:39 +0000
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-18 17:47 +0200
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-18 10:49 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-19 15:16 +0200
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-19 07:58 -0700
Re: Build Systems Öö Tiib <ootiib@hot.ee> - 2023-08-19 09:05 -0700
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-15 12:48 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-15 21:36 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-15 21:43 +0100
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-15 14:07 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-16 12:46 +0200
Really? (Was: Build Systems) gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-15 13:15 +0000
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-15 09:54 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-15 11:07 +0100
Re: Build Systems Öö Tiib <ootiib@hot.ee> - 2023-08-15 03:42 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-15 12:14 +0100
Re: Build Systems Öö Tiib <ootiib@hot.ee> - 2023-08-15 05:53 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-15 15:57 +0100
Re: Build Systems Öö Tiib <ootiib@hot.ee> - 2023-08-15 09:10 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-14 14:49 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-14 14:39 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-15 11:08 +0200
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-15 02:56 -0700
Re: Build Systems Öö Tiib <ootiib@hot.ee> - 2023-08-15 03:23 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-15 11:45 +0100
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-15 03:53 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-15 13:15 +0100
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-15 06:22 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-16 01:20 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-16 12:57 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-16 12:19 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-16 15:18 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-16 18:12 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-16 18:18 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-16 17:45 +0000
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-15 15:30 +0200
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-15 06:58 -0700
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-15 14:06 +0000
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-15 17:08 +0200
Re: Build Systems Vir Campestris <vir.campestris@invalid.invalid> - 2023-08-15 21:46 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-14 15:48 +0000
Re: Build Systems Thiago Adams <thiago.adams@gmail.com> - 2023-08-15 12:16 -0700
Re: Build Systems Michael S <already5chosen@yahoo.com> - 2023-08-29 04:43 -0700
Page 14 of 16 — ← Prev page 1 … 12 13 [14] 15 16 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-17 19:51 +0100 |
| Message-ID | <ublq7g$3skme$1@dont-email.me> |
| In reply to | #172362 |
On 16/08/2023 11:52, David Brown wrote: > On 16/08/2023 11:34, Malcolm McLean wrote: >> My understanding of Lua is that, whilst it can be used as a standalone >> language, it's really meant for adding scripting to applications. > > Certainly embedding it within other applications is a major purpose of > the language, yes. And to that end, Lua is a small language that can be implemented in a few 100KB, including as one DLL file. I think Tiny C can also be used as a bundled backend. But, I'm confused: according to you, it doesn't matter at all how big any product is, since hardware resources are essentially unlimited. So why is it better that a product like Lua is small and self-contained? Why would it matter if it was 100MB and embedding it involved grappling with 25,000 source files across 3,000 nested folders and took an hour extra to build, dwarfing half the products it was used with? Yet, when *I* try and keep my products small, compact and streamlined, then it is apparently totally pointless. You told me my aims are so futile, I should give up, and buy a Linux machine and become just another cog. A bit like telling an amateur film-maker to give that up and buy a cinema season-ticket instead. > It is becoming more mature as a stand-alone > language, with more libraries, but it is very popular for adding to > other programs. As you say, Lua is a common choice for scripting in > games. I used it myself as a scripting language in an embedded program, > many moons ago. > >> If you're >> writing the game level editor then of course the programmer works >> closely with the users, and it's acceptable to have the level editor >> call a binary executable. But if you want scripting in the game itself >> then >> you have to include the Lua source code. >> >> S yes, users rather than developers of Lua itself have to be able to >> incorporate it into a project and compile it easily. >> > > Sure. But if you want to do that, you read the relevant sections of the > manual and see which files you need, which options you want, what > configuration you want, and how you should combine it with your own > code. I'm working on something like that right now. A much smaller, more dynamic, more easily embeddable version of my current scripting language. Totally futile of course. But it is my choice. Making things small, compact, simple and fast isn't that easy.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-18 16:44 +0200 |
| Message-ID | <ubo03m$9ukr$1@dont-email.me> |
| In reply to | #172473 |
On 17/08/2023 20:51, Bart wrote: > On 16/08/2023 11:52, David Brown wrote: > > On 16/08/2023 11:34, Malcolm McLean wrote: > >> My understanding of Lua is that, whilst it can be used as a standalone > >> language, it's really meant for adding scripting to applications. > > > > Certainly embedding it within other applications is a major purpose of > > the language, yes. > > And to that end, Lua is a small language that can be implemented in a > few 100KB, including as one DLL file. > > I think Tiny C can also be used as a bundled backend. > > But, I'm confused: according to you, it doesn't matter at all how big > any product is, since hardware resources are essentially unlimited. If you are confused, that is because you either don't read what I write, or you infer incorrectly from what you imagine I wrote. And sometimes I might be unclear in what I write. But I thought I was really quite explicit in saying that size rarely matters on big systems (like PC's), but is very important on most small embedded systems. To be fair, however, "embedded" can mean two things here - "included inside another program" or "electronics in some object, usually much less powerful than a PC or modern mobile telephone". So if I have a program on my Linux or Windows system that has use of an embedded scripting language, I really don't care if it uses an so or DLL that is 100 KB or 100 MB. If I am adding a scripting language to an embedded microcontroller, I /do/ care. > > So why is it better that a product like Lua is small and self-contained? > > Why would it matter if it was 100MB and embedding it involved grappling > with 25,000 source files across 3,000 nested folders and took an hour > extra to build, dwarfing half the products it was used with? > It matters depending on the target system - PC's have no problem with 100MB of files, but a small microcontroller /does/ have a problem with it. Of course for any system you will also want to have modularisation and compartmentalisation. If you have a program that is getting big enough, you will usually want to split it into DLL's / so files - that makes development far easier as different teams will work on different parts, and communicate through well-defined interfaces. That does not apply in the same way to most small embedded systems, where dynamic linking is not an option. But if you wanted Python as a scripting language in your PC application, you'd have Python DLL's (and probably not bother compiling them yourself at all), whereas Lua is small enough that you might choose to build it directly with your application instead. This is all common sense - I don't know why you find it difficult to understand. > Yet, when *I* try and keep my products small, compact and streamlined, > then it is apparently totally pointless. Write your own programs the way you want to. But don't try to tell others that your programs are great because they are small, and others are terrible because they are big. If size doesn't matter on the target system, then being small - as an aim in itself - is pointless. It really is that simple. Size of the source code can, of course, have an influence on its maintainability and how easy it is to work with the source. But it is not close to being the most important aspect - how well the code is written, organised and documented are much more important. It's the same with speed. Unless you are competing in some benchmark competition, then speed is not helpful as an overriding concern. If something is fast enough, it is fast enough - faster will then not be better. It is only when the speed translates to something important that it is relevant. So if faster software on your fitness armband means the microcontroller can spend more time in sleep mode and thus your battery lasts longer, then speed is important. But if it means your compile time is 0.1 seconds instead of 0.2 seconds, it does not matter at all. And if the advanced compiler time on the PC takes an hour, but reduces the run-time on the armband by 10%, saving 10% battery power, then the advanced compiler is much better. Can you understand the difference here? > > You told me my aims are so futile, I should give up, and buy a Linux > machine and become just another cog. I'm just suggesting something that you might enjoy more than endlessly tilting at windmills. > > A bit like telling an amateur film-maker to give that up and buy a > cinema season-ticket instead. > > > > It is becoming more mature as a stand-alone > > language, with more libraries, but it is very popular for adding to > > other programs. As you say, Lua is a common choice for scripting in > > games. I used it myself as a scripting language in an embedded program, > > many moons ago. > > > >> If you're > >> writing the game level editor then of course the programmer works > >> closely with the users, and it's acceptable to have the level editor > >> call a binary executable. But if you want scripting in the game itself > >> then > >> you have to include the Lua source code. > >> > >> S yes, users rather than developers of Lua itself have to be able to > >> incorporate it into a project and compile it easily. > >> > > > > Sure. But if you want to do that, you read the relevant sections of the > > manual and see which files you need, which options you want, what > > configuration you want, and how you should combine it with your own > > code. > > I'm working on something like that right now. A much smaller, more > dynamic, more easily embeddable version of my current scripting language. > > Totally futile of course. But it is my choice. Making things small, > compact, simple and fast isn't that easy. > The futility or not depends on your aims, what you try to do with it, and how you market it. If you make a simple little language then go to the Lua forums and tell everyone how crap and bloated Lua is, then your effort is futile. If you make a decent little language with documentation, examples and information, gather users and feedback (and listen to that feedback), and build it as a community and a new alternative as an embeddable scripting language with enthusiasts using it, maintaining it, improving it, and supporting it, then that would be fantastic. I'd be happy to consider it for my own use - and certainly happy for your achievement. I know you are capable of taking the second path here. I worry, based on years of Usenet posting, that you will take the first path. There is a third option - you do this just as a hobby for your own interests and enjoyment, and understand its limitations, and that's great too. It's only futile when you build yourself a tree-house and tell people it's better than the Empire State Building, and that you are fighting against bloated and inefficient houses.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-18 08:21 -0700 |
| Message-ID | <9eae4e9b-aab7-4b21-8788-c74f6c898ad8n@googlegroups.com> |
| In reply to | #172499 |
On Friday, 18 August 2023 at 15:44:21 UTC+1, David Brown wrote:\> >But if you wanted Python as a scripting language in your > PC application, you'd have Python DLL's (and probably not bother > compiling them yourself at all), whereas Lua is small enough that you > might choose to build it directly with your application instead. > Exactly. Weight matters. Lua is embeddable as scripting language whilst Python is not. > > It's the same with speed. Unless you are competing in some benchmark > competition, then speed is not helpful as an overriding concern. If > something is fast enough, it is fast enough - faster will then not be > better > it's very important for us because we write interactive tools to deal with vector artwork. The more artwork the artists can throw at us whilst keeping the tool smooth and responsive, the more they will use it. > > If you make a decent little language with documentation, examples and > information, gather users and feedback (and listen to that feedback), > and build it as a community and a new alternative as an embeddable > scripting language with enthusiasts using it, maintaining it, improving > it, and supporting it, then that would be fantastic. I'd be happy to > consider it for my own use - and certainly happy for your achievement. > I did that with MiniBasic. I expected it to be used as a scripting language for big hosted applications. But in fact it found its niche on micro- controllers. I did consider getting a Raspberry PI. But electronics isn't my game.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-08-18 15:39 +0000 |
| Message-ID | <6hMDM.190688$ens9.93860@fx45.iad> |
| In reply to | #172502 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >On Friday, 18 August 2023 at 15:44:21 UTC+1, David Brown wrote:\> >>But if you wanted Python as a scripting language in your >> PC application, you'd have Python DLL's (and probably not bother >> compiling them yourself at all), whereas Lua is small enough that you >> might choose to build it directly with your application instead. >> >Exactly. Weight matters. Lua is embeddable as scripting language whilst >Python is not. I might argue that a bit. We have a mode in our product that supports python as a scripting language. Our product is built as a shared object and can be linked into python at runtime using the python C++ shim provided by the swig package. Or it can be linked with a small interpreter of our own. https://www.swig.org/tutorial.html There are some performance implications, because python isn't very thread friendly, but it generally works. We use it as a unit test framework.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-18 17:47 +0200 |
| Message-ID | <ubo3qd$affo$1@dont-email.me> |
| In reply to | #172502 |
On 18/08/2023 17:21, Malcolm McLean wrote: > On Friday, 18 August 2023 at 15:44:21 UTC+1, David Brown wrote:\> >> But if you wanted Python as a scripting language in your >> PC application, you'd have Python DLL's (and probably not bother >> compiling them yourself at all), whereas Lua is small enough that you >> might choose to build it directly with your application instead. >> > Exactly. Weight matters. Lua is embeddable as scripting language whilst > Python is not. Python is regularly used as an embedded scripting language. But the implementation of the embedded is normally done by DLL's or other separately compiled dynamic libraries or executables. To the user of the main application, however, it is an embedded scripting language. >> >> It's the same with speed. Unless you are competing in some benchmark >> competition, then speed is not helpful as an overriding concern. If >> something is fast enough, it is fast enough - faster will then not be >> better >> > it's very important for us because we write interactive tools to deal with > vector artwork. The more artwork the artists can throw at us whilst > keeping the tool smooth and responsive, the more they will use it. Execution speed is still not your only overriding concern. I believe you are working in the games industry. If it is nearing Christmas, and you tell your boss "give me two more months and I can get another 2% faster", the answer will be "no". There are /always/ balances. But gaming is an area where speed is definitely very important.
[toc] | [prev] | [next] | [standalone]
| From | bart c <bart4858@gmail.com> |
|---|---|
| Date | 2023-08-18 10:49 -0700 |
| Message-ID | <20cd8b90-23f6-4c04-9dbb-88f46aadc8c7n@googlegroups.com> |
| In reply to | #172499 |
On Friday, 18 August 2023 at 15:44:21 UTC+1, David Brown wrote: > On 17/08/2023 20:51, Bart wrote: > > I'm working on something like that right now. A much smaller, more > > dynamic, more easily embeddable version of my current scripting language. > > > > Totally futile of course. But it is my choice. Making things small, > > compact, simple and fast isn't that easy. > > > The futility or not depends on your aims, what you try to do with it, > and how you market it. > > If you make a simple little language then go to the Lua forums and tell > everyone how crap and bloated Lua is, then your effort is futile. > > If you make a decent little language with documentation, examples and > information, gather users and feedback (and listen to that feedback), > and build it as a community and a new alternative as an embeddable > scripting language with enthusiasts using it, maintaining it, improving > it, and supporting it, then that would be fantastic. I'd be happy to > consider it for my own use - and certainly happy for your achievement. No one would be interested in any scripting language I created. Modern scripting languages bristle with advanced features and disregard fundamental ones, while mine are the opposite. As for Lua, while the EXE is the same size as my Q interpreter, the latter has more capability of the kind I find useful (eg. built-in FFI, bignums, record types, bit arrays, but this is not the place to go into it). > I know you are capable of taking the second path here. I worry, based > on years of Usenet posting, that you will take the first path. > > There is a third option - you do this just as a hobby for your own > interests and enjoyment, and understand its limitations, and that's > great too. Q can give Python a run for its money too in features and in speed. However this is not a conventional project since I'm responsible for 100% of the language, of the implementation, of the implementation language, /its/ implementation, of the ultra-simple and near-instant build process it uses. It's quite an achievement ... > It's only futile when you build yourself a tree-house and tell people > it's better than the Empire State Building, and that you are fighting > against bloated and inefficient houses. ... but I'm not allowed to boast about it because people like you will always cut me down to size. Because something that's big complex, successful, used by lots of people and that requires labyrinthine makefiles to build *must* be better. Even when it lacks fundamental features and is slow. That's like saying I can't cook myself a decent meal in my own kitchen; it can't possibly be as good as something mass-produced in a factory with industrial-scale machinery and consumed by a million people. I guess it I was to produce a tool that took the C sources of CPython and produced a working set of .exe/.dll files in one second, using a 10-line script, that wouldn't cut any ice either. You will be constantly looking at ways to belittle it. Because it can't be /that/ simple to build software, it just can't, dammit! (I don't have such a tool and have no plans for one. I can't remember if I tried bcc on CPython, but there were likely insurmountable obstacles before you could get anywhere near compiling a .c file. I can't really cook either.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-19 15:16 +0200 |
| Message-ID | <ubqfcb$r8ff$1@dont-email.me> |
| In reply to | #172506 |
On 18/08/2023 19:49, bart c wrote: > On Friday, 18 August 2023 at 15:44:21 UTC+1, David Brown wrote: >> There is a third option - you do this just as a hobby for your own >> interests and enjoyment, and understand its limitations, and >> that's great too. > > Q can give Python a run for its money too in features and in speed. /That/ is why you get ridiculed. I don't doubt that Q is fast. I /do/ doubt that it is remotely comparable to Python in features. > However this is not a conventional project since I'm responsible for > 100% of the language, of the implementation, of the implementation > language, /its/ implementation, of the ultra-simple and near-instant > build process it uses. > > It's quite an achievement ... It certainly is an achievement. (I have always said that about your compilers, languages, and other tools.) So why do you feel the need to ridicule it and bring laughter upon it by making ridiculous claims? When I got my green belt in Judo, it was quite an achievement - a rare one for a fifty-year-old. But if I had posted about it in sports.boxing (note that Judo has no connection with boxing) and claimed I could give Claude van Damme (whose speciality is in completely different martial arts) a run for his money in a fight, what sort of praise do you think I'd get? If I said that Judo bouts can be over in ten or fifteen seconds, therefore boxing matches lasting 45 minutes are inefficient and slow, would people take me seriously? Your tools and languages /are/ achievements of note - celebrate them for what they are, and stop playing the clown by claiming they are something that they are not. > > >> It's only futile when you build yourself a tree-house and tell >> people it's better than the Empire State Building, and that you are >> fighting against bloated and inefficient houses. > > ... but I'm not allowed to boast about it because people like you > will always cut me down to size. > You /do/ need to be cut down to size. You have made neat little niche tools that do exactly what /you/ want them to do for /your/ needs. That's great (and that was not sarcasm). But your tools are not what other people want or need. They do not compare to real languages and serious tools. They are not better, they are not even similar - they can, at best, do a small number of the tasks handled by major languages and tools, and they can, at best, beat them on a small number of minor metrics. So if you were to post saying you'd made a nice little bytecode interpreter for a small IL/IR, suitable for some kinds of simple scripting, I might say that's great. When you then say your tool is practically the same as llvm and the llvm developers are clearly incompetent and inefficient, /then/ you get the negative feedback.
[toc] | [prev] | [next] | [standalone]
| From | bart c <bart4858@gmail.com> |
|---|---|
| Date | 2023-08-19 07:58 -0700 |
| Message-ID | <35f2a7a9-7869-44e4-ba41-745440baeba5n@googlegroups.com> |
| In reply to | #172533 |
On Saturday, 19 August 2023 at 14:17:15 UTC+1, David Brown wrote: > On 18/08/2023 19:49, bart c wrote: > > On Friday, 18 August 2023 at 15:44:21 UTC+1, David Brown wrote: > > >> There is a third option - you do this just as a hobby for your own > >> interests and enjoyment, and understand its limitations, and > >> that's great too. > > > > Q can give Python a run for its money too in features and in speed. > /That/ is why you get ridiculed. I don't doubt that Q is fast. I /do/ > doubt that it is remotely comparable to Python in features. There are some features I value: https://github.com/sal55/langs/blob/master/qbasics.md No doubt Python has many more /advanced/ features which I can't understand and wouldn't use, but it has lots of basic stuff missing. > It certainly is an achievement. (I have always said that about your > compilers, languages, and other tools.) > > So why do you feel the need to ridicule it and bring laughter upon it by > making ridiculous claims? > > > When I got my green belt in Judo, it was quite an achievement - a rare > one for a fifty-year-old. Did you make a living out of it as I did via my languages? > You /do/ need to be cut down to size. > > You have made neat little niche tools that do exactly what /you/ want > them to do for /your/ needs. That's great (and that was not sarcasm). > > But your tools are not what other people want or need. How do you know what other people or need? > They do not compare to real languages and serious tools. I started creating embedded scripting languages for my commercial apps in the late 80s. People here have talked about using embedded languages in their programs. I was doing that over 30 years ago. I also designed and implemented the languages used. I designed and implemented the languages used to write those applications and interpreters. Those add-on languages were used by a variety of OEMs to create add-on products to my applications, which were also internationalised to Dutch, German and French languages. I also wrote the user manuals (and produced them by writing runoff-like scripts, processing them on the application itself, and sending the output as PostScript). So, what I did wasn't a real language or a real tool? Well, people paid real money for it! (BTW the nearest competitor to our product was AutoCAD. Their scripting language was based around Lisp.) > They are not better, they > are not even similar - they can, at best, do a small number of the tasks > handled by major languages and tools, and they can, at best, beat them > on a small number of minor metrics. > > > So if you were to post saying you'd made a nice little bytecode > interpreter for a small IL/IR, suitable for some kinds of simple > scripting, I might say that's great. When you then say your tool is > practically the same as llvm and the llvm developers are clearly > incompetent and inefficient, /then/ you get the negative feedback. And I asked you what was the difference between getting the task done by my product, and the same task via LLVM. You haven't answered that. I've already acknowleged that it can generate faster code. What else that is a positive difference? If somebody writes a compiler for X that uses intermediate C and incorporates a Tcc backend, what difference will they see from a version that instead incorporates gcc or Clang? Apart from the obvious one of the latter being 2 magnitudes bigger and 1-2 magnitudes slower. Similarly, what difference will they see between one using an LLVM backend, versus one using, say, QBE? (https://c9x.me/compile/doc/llvm.html). BTW I haven't said the LLVM developers are incompetent. It's a remarkable product. But for what it does, it's ridiculously big and complicated. It could do with a reboot that eliminates a lot of the cruft. A few years ago somebody reported a build-time for the LLVM binaries which was an estimated 6-12 hours on my then machine; that is crazy.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2023-08-19 09:05 -0700 |
| Message-ID | <90c361f7-0dfd-4f08-98a9-21efa83ab729n@googlegroups.com> |
| In reply to | #172539 |
On Saturday, 19 August 2023 at 17:58:15 UTC+3, bart c wrote: > On Saturday, 19 August 2023 at 14:17:15 UTC+1, David Brown wrote: > > > > So if you were to post saying you'd made a nice little bytecode > > interpreter for a small IL/IR, suitable for some kinds of simple > > scripting, I might say that's great. When you then say your tool is > > practically the same as llvm and the llvm developers are clearly > > incompetent and inefficient, /then/ you get the negative feedback. > > And I asked you what was the difference between getting the task done by my product, and the same task via LLVM. You haven't answered that. > But that is trivial as everything is different, no difference how to look at it ... nothing matches. Workforce: Single person might get tired and his confronting everything around is bad signal. Tools: You claim all tools are bad. Optimizations: LLVM is designed for compile-time, link-time, run-time, and "idle-time" optimization. Compatibility: LLVM is potentially compatible with any architecture.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-15 12:48 -0700 |
| Message-ID | <87350km6hh.fsf@nosuchdomain.example.com> |
| In reply to | #172293 |
Bart <bc@freeuk.com> writes:
[...]
> My recent post goes into this in more detail. But, I've believe the
> ZIP files from the Github Lua repository are incorrect.
You're right.
The GitHub repo for Lua is
https://github.com/lua/lua
It includes (not as part of the repo itself) a number of releases,
including:
https://github.com/lua/lua/archive/refs/tags/v5.4.6.zip
https://github.com/lua/lua/archive/refs/tags/v5.4.6.tar.gz
The lua.org site provides a tarball:
https://www.lua.org/ftp/lua-5.4.6.tar.gz
I don't see any zip files on lua.org.
The zipfile and tarball from the GitHub release match each other, but do
not match the tarball from lua.org.
> So, whose fault is that?
I have no idea, but I hardly think comp.lang.c is the place to complain
about it.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-15 21:36 +0100 |
| Message-ID | <ubgnl4$2v6ih$1@dont-email.me> |
| In reply to | #172324 |
On 15/08/2023 20:48, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: > [...] >> My recent post goes into this in more detail. But, I've believe the >> ZIP files from the Github Lua repository are incorrect. > > You're right. > > The GitHub repo for Lua is > https://github.com/lua/lua > It includes (not as part of the repo itself) a number of releases, > including: > https://github.com/lua/lua/archive/refs/tags/v5.4.6.zip > https://github.com/lua/lua/archive/refs/tags/v5.4.6.tar.gz > > The lua.org site provides a tarball: > https://www.lua.org/ftp/lua-5.4.6.tar.gz > I don't see any zip files on lua.org. > > The zipfile and tarball from the GitHub release match each other, but do > not match the tarball from lua.org. OK, that one was my mistake then. But it means they're both wrong. And if that Mr. DB had downloaded the source code from the Github, then the make instructions he saw on lua.org would not have worked because of a missing makefile. >> So, whose fault is that? > > I have no idea, but I hardly think comp.lang.c is the place to complain > about it. What I'm complaining about is being falsely (and I believe maliciously) accused of incompetence: BC: >> So, whose fault is that? > DB: > Yours - you did not read the build instructions, but ploughed on with > your own guesswork and got into trouble. That doesn't bother you I guess. Although this won't stop DB, who will claim that of course I should have known that different kinds of source 'tarballs' exist for the version of product, and only some of them will work with the given build instructions. Although I did mention Github regarding Lua two days ago; you'd think someone would have told me that was the wrong site to download source code from, if it's so bleeding obvious. As for who is at fault; I'd suggest: (1) The github site for not mentioning anything about it at all, like: 'download the proper tarball from lua.org' if you want to build it. (Why isn't that top layer present anyway?) (2) Even with the correct sources, you'd have to go on a scavenger hunt through lua.org's Readme page to find the right instructions to run 'make' for plain Windows. BTW the thread is about build systems. My contention was that 'make' on Windows (actual Windows not Linux running under Windows) is generally troublesome. I haven't seen evidence to the contrary.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-15 21:43 +0100 |
| Message-ID | <ubgo18$2v6ih$2@dont-email.me> |
| In reply to | #172332 |
On 15/08/2023 21:36, Bart wrote: > As for who is at fault; I'd suggest: > > (1) The github site for not mentioning anything about it at all, like: > 'download the proper tarball from lua.org' if you want to build it. (Why > isn't that top layer present anyway?) > > (2) Even with the correct sources, you'd have to go on a scavenger hunt > through lua.org's Readme page to find the right instructions to run > 'make' for plain Windows. BTW, why does Github (on this project and I've seen it on others) provide both .zip and .tar.gz sources? According to DB, processing .tar.gz files is so utterly trivial that there appears to be little point to using .zip. People who prefer .zip will of course choose that if both are options.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-15 14:07 -0700 |
| Message-ID | <87ttt0koa5.fsf@nosuchdomain.example.com> |
| In reply to | #172332 |
Bart <bc@freeuk.com> writes:
> On 15/08/2023 20:48, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> My recent post goes into this in more detail. But, I've believe the
>>> ZIP files from the Github Lua repository are incorrect.
>> You're right.
>> The GitHub repo for Lua is
>> https://github.com/lua/lua
>> It includes (not as part of the repo itself) a number of releases,
>> including:
>> https://github.com/lua/lua/archive/refs/tags/v5.4.6.zip
>> https://github.com/lua/lua/archive/refs/tags/v5.4.6.tar.gz
>> The lua.org site provides a tarball:
>> https://www.lua.org/ftp/lua-5.4.6.tar.gz
>> I don't see any zip files on lua.org.
>> The zipfile and tarball from the GitHub release match each other,
>> but do
>> not match the tarball from lua.org.
>
> OK, that one was my mistake then. But it means they're both wrong. And
> if that Mr. DB had downloaded the source code from the Github, then
> the make instructions he saw on lua.org would not have worked because
> of a missing makefile.
>
>>> So, whose fault is that?
>> I have no idea, but I hardly think comp.lang.c is the place to
>> complain
>> about it.
>
> What I'm complaining about is being falsely (and I believe
> maliciously) accused of incompetence:
You're far too quick to assume malice.
> BC:
>>> So, whose fault is that?
>>
> DB:
>> Yours - you did not read the build instructions, but ploughed on with
>> your own guesswork and got into trouble.
I won't attempt to speak for DB, but I doubt that it occurred to him
that the release files on GitHub differ so substantially from the
.tar.gz files on lua.org.
> That doesn't bother you I guess. Although this won't stop DB, who will
> claim that of course I should have known that different kinds of
> source 'tarballs' exist for the version of product, and only some of
> them will work with the given build instructions.
>
> Although I did mention Github regarding Lua two days ago; you'd think
> someone would have told me that was the wrong site to download source
> code from, if it's so bleeding obvious.
It's not obvious, and nobody has said that it is. I would have assumed
that the release .tar.gz file from GitHub was similar to the .tar.gz
file from lua.org until I checked.
> As for who is at fault; I'd suggest:
>
> (1) The github site for not mentioning anything about it at all, like:
> 'download the proper tarball from lua.org' if you want to build
> it. (Why isn't that top layer present anyway?)
GitHub release files are just packaged copies of the files in the repo.
The release tarball from lua.org is built from that. For example, the
GitHub repo includes documentation in what appears to be a
project-specific format; the lua.org release includes generated man
pages and html files.
The README.md file says: "Download official Lua releases from Lua.org.".
Yes, the presence of the "release" files on GitHub is misleading. Now
that we've established that, can we stop complaining about it here?
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-16 12:46 +0200 |
| Message-ID | <ubi9da$394g8$1@dont-email.me> |
| In reply to | #172338 |
On 15/08/2023 23:07, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: >> On 15/08/2023 20:48, Keith Thompson wrote: >>> Bart <bc@freeuk.com> writes: >>> [...] >>>> My recent post goes into this in more detail. But, I've believe the >>>> ZIP files from the Github Lua repository are incorrect. >>> You're right. >>> The GitHub repo for Lua is >>> https://github.com/lua/lua >>> It includes (not as part of the repo itself) a number of releases, >>> including: >>> https://github.com/lua/lua/archive/refs/tags/v5.4.6.zip >>> https://github.com/lua/lua/archive/refs/tags/v5.4.6.tar.gz >>> The lua.org site provides a tarball: >>> https://www.lua.org/ftp/lua-5.4.6.tar.gz >>> I don't see any zip files on lua.org. >>> The zipfile and tarball from the GitHub release match each other, >>> but do >>> not match the tarball from lua.org. >> >> OK, that one was my mistake then. But it means they're both wrong. And >> if that Mr. DB had downloaded the source code from the Github, then >> the make instructions he saw on lua.org would not have worked because >> of a missing makefile. >> >>>> So, whose fault is that? >>> I have no idea, but I hardly think comp.lang.c is the place to >>> complain >>> about it. >> >> What I'm complaining about is being falsely (and I believe >> maliciously) accused of incompetence: > > You're far too quick to assume malice. > >> BC: >>>> So, whose fault is that? >>> >> DB: >>> Yours - you did not read the build instructions, but ploughed on with >>> your own guesswork and got into trouble. > > I won't attempt to speak for DB, but I doubt that it occurred to him > that the release files on GitHub differ so substantially from the > .tar.gz files on lua.org. It did not surprise me at all that they are different - github is primarily for development, not standard tested releases. If you want to download a proper release for a project, you go to the project website, and follow the pointers there. (For some projects, the github pages and readme.md /is/ the main website - but that is clearly not the case here.) However, it did surprise me that the GitHub repository is /so/ different from the released tarballs from the main site. The directory structures are different, and the makefiles are significantly different - in the release tarballs, they are aimed at configuring and installing (thus having things like platform selection options), while in the GitHub they are aimed at development (so lots of warning flags). The actual source files seem the same. > >> That doesn't bother you I guess. Although this won't stop DB, who will >> claim that of course I should have known that different kinds of >> source 'tarballs' exist for the version of product, and only some of >> them will work with the given build instructions. >> >> Although I did mention Github regarding Lua two days ago; you'd think >> someone would have told me that was the wrong site to download source >> code from, if it's so bleeding obvious. > > It's not obvious, and nobody has said that it is. I would have assumed > that the release .tar.gz file from GitHub was similar to the .tar.gz > file from lua.org until I checked. Note, however, that people /did/ tell Bart to look at the build instructions on the Lua site (including suggesting looking at the "Detailed instructions"). And in the GitHub page, there is an "About" that says "The Lua development repository, as seen by the Lua team. Mirrored irregularly." There's a link to the project site. > >> As for who is at fault; I'd suggest: >> >> (1) The github site for not mentioning anything about it at all, like: >> 'download the proper tarball from lua.org' if you want to build >> it. (Why isn't that top layer present anyway?) > > GitHub release files are just packaged copies of the files in the repo. > The release tarball from lua.org is built from that. For example, the > GitHub repo includes documentation in what appears to be a > project-specific format; the lua.org release includes generated man > pages and html files. > > The README.md file says: "Download official Lua releases from Lua.org.". > > Yes, the presence of the "release" files on GitHub is misleading. Now > that we've established that, can we stop complaining about it here? > > [...] >
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2023-08-15 13:15 +0000 |
| Subject | Really? (Was: Build Systems) |
| Message-ID | <ubftpe$3jnmn$1@news.xmission.com> |
| In reply to | #172245 |
In article <ubfeqj$2oop4$1@dont-email.me>, David Brown <david.brown@hesbynett.no> wrote: ... >This is not a "campaign against you". Of course it is. But it is absolutely obligatory, when launching a campaign against someone, to deny that you are doing so. So, well done. You are sticking to form. -- "Unattended children will be given an espresso and a free kitten."
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-15 09:54 +0200 |
| Message-ID | <ubfave$2o5nd$1@dont-email.me> |
| In reply to | #172224 |
On 14/08/2023 15:58, Bart wrote: > On 14/08/2023 14:06, David Brown wrote: > > On 13/08/2023 22:45, Ben Bacarisse wrote: > >> Bart <bc@freeuk.com> writes: > >> > > > >>> Lua Interpreter: This had a makefile, but gave errors. > >> > >> Linux software, does not compile without effort on Windows. In other > >> news, bear defecates in the woods. > >> > >>> A closer look > >>> revealed things like "-DLINUX...". I know this builds on Windows, but > >>> there > >>> was no info as to how that I could see. > >> > >> They make it hard. It's hidden on the download page under the heading > >> "Building" with the confusing link "detailed instructions". > >> > >> But again, what has this do with make? > >> > > > > I opened a command prompt on my Windows PC, downloaded lua source and > > built it according to the "detailed instructions". All told, it took > > about a minute, including reading the instructions. "make" on Windows > > works fine. > > So, how did you do it? I assume this is proper Windows and not WSL. > Yes, "proper" Windows. I have msys2/mingw64 installed. (I haven't used it for several years, because I haven't needed it.) I followed the instructions - "curl" to download the lua tarball, "tar" to extract it, then "cd" into the directory. As noted on the "detailed instructions", I tried "make" and found it failed to guess the platform exactly. So I then - as directed by the instructions - used "make mingw". Then I had "lua.exe" and "luac.exe" build. > On the downloaded source bundle from Github, there were no such > instructions. The "readme" file says "For complete information about Lua, visit lua.org." Seriously, how much spoonfeeding do you need? Is it /that/ hard to read a few lines on a webpage?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-15 11:07 +0100 |
| Message-ID | <ubfipj$2pcjc$1@dont-email.me> |
| In reply to | #172243 |
On 15/08/2023 08:54, David Brown wrote:
> On 14/08/2023 15:58, Bart wrote:
>> On 14/08/2023 14:06, David Brown wrote:
>> > On 13/08/2023 22:45, Ben Bacarisse wrote:
>> >> Bart <bc@freeuk.com> writes:
>> >>
>> >
>> >>> Lua Interpreter: This had a makefile, but gave errors.
>> >>
>> >> Linux software, does not compile without effort on Windows. In
other
>> >> news, bear defecates in the woods.
>> >>
>> >>> A closer look
>> >>> revealed things like "-DLINUX...". I know this builds on Windows,
>> but
>> >>> there
>> >>> was no info as to how that I could see.
>> >>
>> >> They make it hard. It's hidden on the download page under the
>> heading
>> >> "Building" with the confusing link "detailed instructions".
>> >>
>> >> But again, what has this do with make?
>> >>
>> >
>> > I opened a command prompt on my Windows PC, downloaded lua source and
>> > built it according to the "detailed instructions". All told, it took
>> > about a minute, including reading the instructions. "make" on
Windows
>> > works fine.
>>
>> So, how did you do it? I assume this is proper Windows and not WSL.
>>
>
> Yes, "proper" Windows. I have msys2/mingw64 installed. (I haven't used
> it for several years, because I haven't needed it.) I followed the
> instructions - "curl" to download the lua tarball, "tar" to extract it,
> then "cd" into the directory.
" but here is a simple terminal session that downloads the current
release of Lua and builds it in Linux:"
Proper Windows indeed!
> As noted on the "detailed instructions",
> I tried "make" and found it failed to guess the platform exactly. So I
> then - as directed by the instructions - used "make mingw". Then I had
> "lua.exe" and "luac.exe" build.
OK, you got me. There one mention of "mingw" (not "make mingw") on this
page:
https://www.lua.org/manual/5.4/readme.html
It is in a section called Building Lua which starts with:
"In most common UNIX-LIKE platforms, simply do "make". Here are the
details." (My emphasis)
In subsection 3, "mingw" occurs in this list, all well-known versions of
Windows:
"guess aix bsd c89 freebsd generic ios linux linux-readline
macosx mingw posix solaris"
Silly me for not spotting that and looking ahead to a section called:
"Building Lua on other systems"
Which starts with:
"If you're not using the usual Unix tools,"
Not exactly crystal clear is it.
This reminds of forums where people complaing of being caught out on
some parking infringement because the signs were not clear. And others
say of course they were clear: all the rules were explained in the small
print at the bottom of that sign placed 12' up that post, /inside/ the
car park!
Of course, even after all that, I extract a fresh copy of the
'lua-master' folders, do 'make mingw', and it says:
make: *** No rule to make target 'mingw'. Stop.
So NOW what am I doing wrong?
One thing that you must acknowledges is that those build instructions
could surely be less Unix-centric and could even have a special section
for Windows.
It is after all hardly a minor or uncommon OS. You don't really want to
scour it for clues within the 'small print'.
The only mention of Windows on that page is a suggestion to generate a
DLL instead (why?).
>> On the downloaded source bundle from Github, there were no such
>> instructions.
>
> The "readme" file says "For complete information about Lua, visit
lua.org."
>
> Seriously, how much spoonfeeding do you need? Is it /that/ hard to read
> a few lines on a webpage?
How hard is it to just say:
# For building on Windows use 'make mingw'
within the makefile? (Slightly harder is to ensure it works.)
Now I KNOW this is personal. You will not acknowledge that the build
instructions could be better; it HAS to be my fault.
NOTES
(1) Note that under Building Lua it says:
"Open a terminal window and move to the top-level directory, which is
named lua-5.4.6."
My directory isn't called lua-5.4.6. It's called "lua-master". It was
obtained from https://github.com/lua/lua using 'Download ZIP'.
If I go to Releases, then I can get one with the right name, but it's
the same set of files and still doesn't build.
(2) At the end of the day, I did after all get lua.exe, working from the
list of .o files given later on the page.
So no thanks to those earlier instructions, or to 'make'.
> Is it /that/ hard to read a few lines on a webpage?
Hand-on-heart, would you say that page was clearly written for Windows
users?
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2023-08-15 03:42 -0700 |
| Message-ID | <e723230c-1bcc-45d7-9427-c550672682bfn@googlegroups.com> |
| In reply to | #172248 |
On Tuesday, 15 August 2023 at 13:08:13 UTC+3, Bart wrote: > On 15/08/2023 08:54, David Brown wrote: > > > Is it /that/ hard to read a few lines on a webpage? > > Hand-on-heart, would you say that page was clearly written for Windows > users? You mean that page? <http://lua-users.org/wiki/BuildingLua> IMHO it explains all ways of building it on Windows in detail. That is good indeed as no one knows maybe our use case involves vc6 or borland c or whatever. You are directed there for example by <https://www.lua.org/faq.html#1.1> And FAQ link is right on download page <https://www.lua.org/download.html> "If you have trouble building lua read faq" Or maybe you talk of some other page. I don't know for me the helpfulness there is on side of impressive. Have enjoyed commercial products order of magnitude worse supported.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-15 12:14 +0100 |
| Message-ID | <ubfmn6$2q1af$1@dont-email.me> |
| In reply to | #172251 |
On 15/08/2023 11:42, Öö Tiib wrote:
> On Tuesday, 15 August 2023 at 13:08:13 UTC+3, Bart wrote:
>> On 15/08/2023 08:54, David Brown wrote:
>>
>>> Is it /that/ hard to read a few lines on a webpage?
>>
>> Hand-on-heart, would you say that page was clearly written for Windows
>> users?
>
> You mean that page? <http://lua-users.org/wiki/BuildingLua>
> IMHO it explains all ways of building it on Windows in detail. That
is good
> indeed as no one knows maybe our use case involves vc6 or borland c
> or whatever.
>
> You are directed there for example by <https://www.lua.org/faq.html#1.1>
> And FAQ link is right on download page
<https://www.lua.org/download.html>
> "If you have trouble building lua read faq"
>
> Or maybe you talk of some other page. I don't know for me the helpfulness
> there is on side of impressive. Have enjoyed commercial products order
> of magnitude worse supported.
>
From what Ben and David have said, the start point appears to be this:
https://www.lua.org/
This is the site mentioned in the makefile in the sources. Clicking on
/downloads/ as I think Ben said (remember I've already downloaded the
sources), takes you here:
https://www.lua.org/download.html
Under Building it says 'Lua is very easy to build and install'. There is
a linked called 'detailed instructions' which has been mentioned by BB
and DB, which takes you to:
https://www.lua.org/manual/5.4/readme.html
This is the page I'm referring to.
Your link does at least mention 'make mingw' directly, but also in the
context of mingw-msys; I don't know what that is. In all it is a lot
more complicated and confusing.
To build 5.4.6, from the top-level folder lua-5.4.6 which contains all
the .c and .h files, I created this file 'fred' (using 'dir/b *.c >fred,
then editing to remove the ones not needed, like luac.c), which contains:
lua.c
lapi.c
lcode.c
lctype.c
ldebug.c
ldo.c
ldump.c
lfunc.c
lgc.c
llex.c
lmem.c
lobject.c
lopcodes.c
lparser.c
lstate.c
lstring.c
ltable.c
ltm.c
lundump.c
lvm.c
lzio.c
lauxlib.c
lbaselib.c
lcorolib.c
ldblib.c
liolib.c
lmathlib.c
loadlib.c
loslib.c
lstrlib.c
ltablib.c
lutf8lib.c
linit.c
(Note: lua.c being first means no output file needed for bcc/lcc, as
they use the name of the first file.)
I then typed:
gcc -lua @fred
to get lua.exe. Now you can tweak the build using -O3 and -s for
example. Those options get you a 350KB executable.
Using 'bcc -old @fred' gets me a 340KB lua.exe. While 'tcc @fred'
creates a 370KB one.
I even started WSL, and typed this (note it needs that utterly pointless
-lm flag):
gcc -lua @fred -lm
and got lua (that is, the executable file 'lua'; an extension would be
useful!) running under Linux. So my simple script is cross-platform too!
THAT is simple. Now tell me what CMake would bring to the table.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2023-08-15 05:53 -0700 |
| Message-ID | <24224c26-638f-4974-ab3d-ee5cbc8bf2ecn@googlegroups.com> |
| In reply to | #172257 |
On Tuesday, 15 August 2023 at 14:15:03 UTC+3, Bart wrote: > On 15/08/2023 11:42, Öö Tiib wrote: > > On Tuesday, 15 August 2023 at 13:08:13 UTC+3, Bart wrote: > >> On 15/08/2023 08:54, David Brown wrote: > >> > >>> Is it /that/ hard to read a few lines on a webpage? > >> > >> Hand-on-heart, would you say that page was clearly written for Windows > >> users? > > > > You mean that page? <http://lua-users.org/wiki/BuildingLua> > > IMHO it explains all ways of building it on Windows in detail. That > is good > > indeed as no one knows maybe our use case involves vc6 or borland c > > or whatever. > > > > You are directed there for example by <https://www.lua.org/faq.html#1.1> > > And FAQ link is right on download page > <https://www.lua.org/download.html> > > "If you have trouble building lua read faq" > > > > Or maybe you talk of some other page. I don't know for me the helpfulness > > there is on side of impressive. Have enjoyed commercial products order > > of magnitude worse supported. > > > From what Ben and David have said, the start point appears to be this: > > https://www.lua.org/ > > This is the site mentioned in the makefile in the sources. Clicking on > /downloads/ as I think Ben said (remember I've already downloaded the > sources), takes you here: > > https://www.lua.org/download.html > > Under Building it says 'Lua is very easy to build and install'. There is > a linked called 'detailed instructions' which has been mentioned by BB > and DB, which takes you to: > > https://www.lua.org/manual/5.4/readme.html > > This is the page I'm referring to. > Yes, it also suggests mingw as xxx for make xxx, when plain make doesn't cut it. > Your link does at least mention 'make mingw' directly, but also in the > context of mingw-msys; I don't know what that is. In all it is a lot > more complicated and confusing. > The MinGW is runtime environment on Windows. Currently there is advancement project MinGW-w64. The MSYS is collection of tools and libraries compatible with MinGW ... it has also advancement project MSYS2. Nothing to do, decades old platform like Windows has accumulated several production tool stacks over time and so there are no one-liner answer that satisfies users of all of those. > To build 5.4.6, from the top-level folder lua-5.4.6 which contains all > the .c and .h files, I created this file 'fred' (using 'dir/b *.c >fred, > then editing to remove the ones not needed, like luac.c), which contains: > > lua.c > lapi.c > lcode.c > lctype.c > ldebug.c > ldo.c > ldump.c > lfunc.c > lgc.c > llex.c > lmem.c > lobject.c > lopcodes.c > lparser.c > lstate.c > lstring.c > ltable.c > ltm.c > lundump.c > lvm.c > lzio.c > lauxlib.c > lbaselib.c > lcorolib.c > ldblib.c > liolib.c > lmathlib.c > loadlib.c > loslib.c > lstrlib.c > ltablib.c > lutf8lib.c > linit.c > > (Note: lua.c being first means no output file needed for bcc/lcc, as > they use the name of the first file.) > That is interpreter. Typically people might want all of lua (the interpreter), luac (the compiler), and liblua (the library). Lua's main appeal is that it is embeddable script engine, and so most usual usage of it is for to make a product scriptable. > I then typed: > > gcc -lua @fred > > to get lua.exe. Now you can tweak the build using -O3 and -s for > example. Those options get you a 350KB executable. > > Using 'bcc -old @fred' gets me a 340KB lua.exe. While 'tcc @fred' > creates a 370KB one. > > I even started WSL, and typed this (note it needs that utterly pointless > -lm flag): > > gcc -lua @fred -lm > > and got lua (that is, the executable file 'lua'; an extension would be > useful!) running under Linux. So my simple script is cross-platform too! > > THAT is simple. Now tell me what CMake would bring to the table. > The CMake is compiler-independent. So it allows easier integration to more varying tools and tool stacks. You might want programmers to edit same product in both Android Studio and XCode, build the product differently instrumented automatically on continuous integration, deploy it to various test systems automatically, test it there automatically, produce reports etc. Without CMake it all is of course possible but may take too much work time of people who can do something more interesting.
[toc] | [prev] | [next] | [standalone]
Page 14 of 16 — ← Prev page 1 … 12 13 [14] 15 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web