[Back to Index]

[00:00] <Dark-Star> anyway, time for me to get some sleep. see ya!
[00:00] <dreammaster> Night
[00:03] --> stroggoff joined #scummvm.
[00:04] <-- noobineer left irc: Remote host closed the connection
[00:06] <-- nasios left irc: Ping timeout: 260 seconds
[00:12] --> noobineer joined #scummvm.

[00:25] <-- noobineer left irc: Read error: Connection reset by peer
[00:25] <-- SylvainTV left irc: Read error: Connection reset by peer
[00:40] --> Drenn joined #scummvm.
[00:42] --> noobineer joined #scummvm.
[00:49] <-- Joefish left irc: Ping timeout: 256 seconds
[01:14] --> GitHub176 joined #scummvm.
[01:14] <GitHub176> [scummvm] dreammaster pushed 1 new commit to master: https://git.io/vx1Gj
[01:14] <GitHub176> scummvm/master e5c4adb Paul Gilbert: XEEN: Fixes for fighting in the Warzone
[01:14] GitHub176 (GitHub176@gateway/service/github.com/x-olfocggiitnugatc) left #scummvm.
[01:46] <-- noobineer left irc: Ping timeout: 276 seconds
[02:01] --> GitHub46 joined #scummvm.
[02:01] <GitHub46> [scummvm] dreammaster pushed 1 new commit to master: https://git.io/vx1cD
[02:01] <GitHub46> scummvm/master 4fefa88 Paul Gilbert: XEEN: Don't allow saving in the war zone
[02:01] GitHub46 (GitHub46@gateway/service/github.com/x-rzajocisxcaeclbu) left #scummvm.
[02:04] --> DominusExult joined #scummvm.
[02:04] <-- Dominus left irc: Ping timeout: 260 seconds
[02:04] Nick change: DominusExult -> Dominus
[02:22] <-- linux_dr left irc: Quit: Connection closed for inactivity
[02:37] <-- qvist left irc: Ping timeout: 256 seconds
[02:43] --> noobineer joined #scummvm.
[02:45] --> qvist joined #scummvm.
[02:45] #scummvm: mode change '+v qvist' by ChanServ!ChanServ@services.
[02:59] --> GitHub40 joined #scummvm.
[02:59] <GitHub40> [scummvm] dreammaster pushed 1 new commit to master: https://git.io/vx1lZ
[02:59] <GitHub40> scummvm/master 73d72f4 Paul Gilbert: XEEN: Fix cmdIfMapFlag crash when banging Winterkill gong
[02:59] GitHub40 (GitHub40@gateway/service/github.com/x-eijfhzqggfyjtovg) left #scummvm.
[02:59] <-- qvist left irc: Ping timeout: 256 seconds
[03:08] <-- Drenn left irc: Ping timeout: 260 seconds
[03:12] --> qvist joined #scummvm.
[03:12] #scummvm: mode change '+v qvist' by ChanServ!ChanServ@services.
[03:18] <-- dreammaster left irc:
[04:04] <-- noobineer left irc: Remote host closed the connection
[05:45] <-- Polynomial-C left irc: Ping timeout: 260 seconds
[05:45] --> Poly-C joined #scummvm.
[05:54] <-- klusark left irc: Ping timeout: 240 seconds
[05:54] --> klusark joined #scummvm.
[07:21] --> Joefish joined #scummvm.
[07:21] #scummvm: mode change '+v Joefish' by ChanServ!ChanServ@services.
[07:32] <Joefish> morning :)
[07:32] <Joefish> hope everyone had a nice easter
[08:07] <Joefish> no way.. LeChuck actually answered me :O
[08:29] <-- LittleToonCat left irc: Remote host closed the connection
[08:41] <-- bonki left irc: Remote host closed the connection
[08:42] --> bonki joined #scummvm.
[08:42] #scummvm: mode change '+o bonki' by ChanServ!ChanServ@services.
[08:44] --> TMM joined #scummvm.
[08:44] <-- TMM left irc: Changing host
[08:44] --> TMM joined #scummvm.
[08:44] #scummvm: mode change '+o TMM' by ChanServ!ChanServ@services.
[09:01] --> phraxoid joined #scummvm.
[09:12] <-- Lightkey left irc: Ping timeout: 245 seconds
[09:26] --> Lightkey joined #scummvm.
[10:06] --> phraxoid_ joined #scummvm.
[10:07] --> DJW|Home joined #scummvm.
[10:07] #scummvm: mode change '+o DJW|Home' by ChanServ!ChanServ@services.
[10:07] --> _sev_ joined #scummvm.
[10:07] #scummvm: mode change '+o _sev_' by ChanServ!ChanServ@services.
[10:07] --> nasios joined #scummvm.
[10:10] --> demonimin_ joined #scummvm.
[10:10] <-- demonimin_ left irc: Changing host
[10:10] --> demonimin_ joined #scummvm.
[10:11] --> _logix joined #scummvm.
[10:11] --> wjp_ joined #scummvm.
[10:11] --> qvist_ joined #scummvm.
[10:11] --> erdic_ joined #scummvm.
[10:14] --> Unseen2a joined #scummvm.
[10:16] TMM (~Hein-Piet@fsf/member/pdpc.professional.tmm) got netsplit.
[10:16] stroggoff (~Praetoria@ppp-94-67-175-131.home.otenet.gr) got netsplit.
[10:16] _sev (~sev@scummvm/undead/sev) got netsplit.
[10:16] demonimin (~demonimin@unaffiliated/demonimin) got netsplit.
[10:16] DJWillis (~djwillis@cpc123798-trow7-2-0-cust28.18-1.cable.virginm.net) got netsplit.
[10:16] erdic (~erdic@unaffiliated/motley) got netsplit.
[10:16] Unseen2 (snowcat@snowcat.de) got netsplit.
[10:16] logix (~logix@ilsa.franken.de) got netsplit.
[10:16] phraxoid (~phraxoid@unaffiliated/phraxoid) got netsplit.
[10:16] qvist (~qvist@delta.ipv7.se) got netsplit.
[10:16] Dominus (~dominus@unaffiliated/dominus) got netsplit.
[10:16] aquadran (aquadran@scummvm/undead/aquadran) got netsplit.
[10:16] wjp (~wjp@hmm.wantstofly.org) got netsplit.
[10:16] Nick change: Unseen2a -> Unseen2
[10:16] Possible future nick collision: Unseen2
[10:16] Nick change: erdic_ -> erdic
[10:16] Possible future nick collision: erdic
[10:17] Nick change: _logix -> logix
[10:17] Possible future nick collision: logix
[10:17] --> TMM joined #scummvm.
[10:17] <-- TMM left irc: Changing host
[10:17] --> TMM joined #scummvm.
[10:17] #scummvm: mode change '+o TMM' by ChanServ!ChanServ@services.
[10:20] --> aquadran joined #scummvm.
[10:27] wjp (~wjp@hmm.wantstofly.org) got lost in the net-split.
[10:27] DJWillis (~djwillis@cpc123798-trow7-2-0-cust28.18-1.cable.virginm.net) got lost in the net-split.
[10:27] demonimin (~demonimin@unaffiliated/demonimin) got lost in the net-split.
[10:27] _sev (~sev@scummvm/undead/sev) got lost in the net-split.
[10:27] stroggoff (~Praetoria@ppp-94-67-175-131.home.otenet.gr) got lost in the net-split.
[10:27] Dominus (~dominus@unaffiliated/dominus) got lost in the net-split.
[10:27] qvist (~qvist@delta.ipv7.se) got lost in the net-split.
[10:27] phraxoid (~phraxoid@unaffiliated/phraxoid) got lost in the net-split.
[10:39] aquadran (aquadran@176.31.209.194) got netsplit.
[10:41] --> aquadran joined #scummvm.
[10:41] --> Dominus joined #scummvm.
[10:45] --> DominusExult joined #scummvm.
[10:46] <-- Dominus left irc: Ping timeout: 260 seconds
[10:46] Nick change: DominusExult -> Dominus
[11:15] <-- DrMcCoy left irc: Ping timeout: 248 seconds
[11:17] --> DrMcCoy joined #scummvm.
[11:17] #scummvm: mode change '+o DrMcCoy' by ChanServ!ChanServ@services.
[11:20] --> jamm joined #scummvm.
[11:20] <-- jamm left irc: Changing host
[11:20] --> jamm joined #scummvm.
[11:25] --> ST joined #scummvm.
[11:25] #scummvm: mode change '+o ST' by ChanServ!ChanServ@services.
[12:28] --> Littleboy joined #scummvm.
[12:28] #scummvm: mode change '+o Littleboy' by ChanServ!ChanServ@services.
[12:32] --> Yuv422 joined #scummvm.
[14:10] <-- Yuv422 left irc: Quit: Yuv422
[14:36] --> ajax16384 joined #scummvm.
[14:36] #scummvm: mode change '+o ajax16384' by ChanServ!ChanServ@services.
[15:05] Nick change: demonimin_ -> demonimin
[15:41] <-- _sev_ left irc: Quit: This computer has gone to sleep
[15:46] --> _sev_ joined #scummvm.
[15:46] #scummvm: mode change '+o _sev_' by ChanServ!ChanServ@services.
[15:48] <-- jamm left irc: Ping timeout: 256 seconds
[15:56] <rsn8887> csnover: I am trying to rebuild the Vita docker worker, but am getting errors: http://deb.debian.org/debian/pool/main/g/gcc-6/cpp-6_6.3.0-18_amd64.deb
[15:56] <rsn8887> Snot found
[15:56] <rsn8887> E: Failed to fetch http://deb.debian.org/debian/pool/main/g/gcc-6/cpp-6_6.3.0-18_amd64.deb 404 Not Found
[15:56] <rsn8887> E: Failed to fetch http://deb.debian.org/debian/pool/main/g/gcc-6/libgomp1_6.3.0-18_amd64.deb 404 Not Found
[15:56] <rsn8887> E: Failed to fetch http://deb.debian.org/debian/pool/main/g/gcc-6/libitm1_6.3.0-18_amd64.deb 404 Not Found
[15:56] <rsn8887> E: Failed to fetch http://deb.debian.org/debian/pool/main/g/gcc-6/libquadmath0_6.3.0-18_amd64.deb 404 Not Found
[15:56] <rsn8887> E: Failed to fetch http://deb.debian.org/debian/pool/main/g/gcc-6/gcc-6_6.3.0-18_amd64.deb 404 Not Found
[15:56] <rsn8887> E: Failed to fetch http://security.debian.org/pool/updates/main/l/linux/linux-libc-dev_4.9.65-3+deb9u2_amd64.deb 404 Not Found
[15:56] <rsn8887> E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
[15:56] <rsn8887> Sorry accidental spam
[15:56] <rsn8887> Shouldn't this be robust against such problems?
[15:59] --> noobineer joined #scummvm.
[16:01] --> ny00123 joined #scummvm.
[16:04] <rsn8887> Oh nevermind you are not here.
[16:19] <-- Cheeseness left irc: Ping timeout: 256 seconds
[16:36] --> Drenn joined #scummvm.
[16:36] --> LittleToonCat joined #scummvm.
[16:40] <Joefish> rsn8887, I'm probably stating the obvious (without knowing your actual problem) but I guess you already run `apt-get update` before to update the mirrors?
[16:41] <rsn8887> I probably made some mistake. I am trying again now.
[16:41] <Joefish> the error just looks too familiar for me not to at least mention it :P
[16:43] <Joefish> btw rsn8887 sorry for not answering on your PR concerning build errors for PSP (because of lilliput). I wasn't around the last couple days. I hope Strangerke answered your questions in chat
[16:43] <rsn8887> Yes it is all working noe.
[16:43] <rsn8887> now
[16:43] <Joefish> great :)
[16:43] <rsn8887> It was a minor fix, I just committed it.
[16:44] <-- noobineer left irc: Ping timeout: 265 seconds
[17:31] --> LubomirR joined #scummvm.
[17:33] <-- |Cable| left irc: Ping timeout: 276 seconds
[17:35] --> Farmboy0 joined #scummvm.
[17:35] <-- Farmboy0 left irc: Changing host
[17:35] --> Farmboy0 joined #scummvm.
[17:41] <-- Littleboy left irc: Ping timeout: 256 seconds
[17:45] --> |Cable| joined #scummvm.
[18:06] <-- Drenn left irc: Ping timeout: 260 seconds
[18:23] <rsn8887> Hmm now Docker hangs on "checking whether we are cross compiling..." for libpng. Autotools sure is a horror.
[18:37] --> SylvainTV joined #scummvm.
[18:37] #scummvm: mode change '+o SylvainTV' by ChanServ!ChanServ@services.
[18:39] --> GitHub1 joined #scummvm.
[18:39] <GitHub1> [scummvm] bgK opened pull request #1156: GUI: Unify clip and non-clip draw calls (master...gui-simplify-text) https://git.io/vxMd2
[18:39] GitHub1 (GitHub1@gateway/service/github.com/x-lxcexwqqjggqbqfs) left #scummvm.
[18:41] --> GitHub23 joined #scummvm.
[18:41] <GitHub23> [scummvm] bgK closed pull request #1148: SDL: Can load game controller DB file + joystick button for virtual keyboard (master...joystick_mapping) https://git.io/vxR2H
[18:41] GitHub23 (GitHub23@gateway/service/github.com/x-fxultoplsqgststw) left #scummvm.
[18:41] --> GitHub9 joined #scummvm.
[18:41] <GitHub9> [scummvm] bgK pushed 1 new commit to master: https://git.io/vxMdS
[18:41] <GitHub9> scummvm/master f0dfc19 LMerckx: SDL: Allow to load a custom game controller mapping file...
[18:41] GitHub9 (GitHub9@gateway/service/github.com/x-dfygkkbfrmqzmzff) left #scummvm.
[18:45] <-- _sev_ left irc: Quit: This computer has gone to sleep
[18:46] --> _sev joined #scummvm.
[18:46] #scummvm: mode change '+o _sev' by ChanServ!ChanServ@services.
[19:05] <-- DrMcCoy left irc: Ping timeout: 260 seconds
[19:06] --> DrMcCoy joined #scummvm.
[19:06] #scummvm: mode change '+o DrMcCoy' by ChanServ!ChanServ@services.
[19:13] <-- |Cable| left irc: Ping timeout: 260 seconds
[19:13] --> criezy joined #scummvm.
[19:13] #scummvm: mode change '+o criezy' by ChanServ!ChanServ@services.
[19:25] --> |Cable| joined #scummvm.
[19:34] <-- ajax16384 left irc: Read error: Connection reset by peer
[19:56] <-- Farmboy0 left irc: Remote host closed the connection
[19:57] --> Farmboy0 joined #scummvm.
[19:57] <-- Farmboy0 left irc: Changing host
[19:57] --> Farmboy0 joined #scummvm.
[19:58] --> Drenn joined #scummvm.
[20:06] <_sev> does anyone have valgrind handy?
[20:08] --> GitHub114 joined #scummvm.
[20:08] <GitHub114> [scummvm-tools] sev- pushed 2 new commits to master: https://git.io/vxDJY
[20:08] <GitHub114> scummvm-tools/master 1b32a32 Eugene Sandulenko: TOOLS: Fix indentation
[20:08] <GitHub114> scummvm-tools/master 66e3aec Eugene Sandulenko: TOOLS: Switch to print() in extract_prince
[20:08] GitHub114 (GitHub114@gateway/service/github.com/x-icjkuccolkxrxozk) left #scummvm.
[20:16] <-- phraxoid_ left irc: Quit: Quit
[20:21] <_sev> wjp_: here?
[20:36] --> Yuv422 joined #scummvm.
[20:42] --> GitHub51 joined #scummvm.
[20:42] <GitHub51> [scummvm] sev- pushed 1 new commit to master: https://git.io/vxDkj
[20:42] <GitHub51> scummvm/master 21ef072 Eugene Sandulenko: BLADERUNNER: Fix memory leaks
[20:42] GitHub51 (GitHub51@gateway/service/github.com/x-ukedvbyobuhvncyq) left #scummvm.
[20:45] <-- Drenn left irc: Ping timeout: 255 seconds
[20:49] <-- Yuv422 left irc: Quit: Yuv422
[20:50] --> GitHub91 joined #scummvm.
[20:50] <GitHub91> [scummvm] bonki pushed 1 new commit to master: https://git.io/vxDIF

[20:50] GitHub91 (GitHub91@gateway/service/github.com/x-ndsjhygeaafunfay) left #scummvm.
[20:57] --> GitHub80 joined #scummvm.
[20:57] <GitHub80> [scummvm] bonki closed pull request #1154: COMMON: Add WARN_UNUSED_RESULT to scummsys.h (master...bonki-common-warn-unused-result) https://git.io/vx2Hu
[20:57] GitHub80 (GitHub80@gateway/service/github.com/x-xmknezcifgnsjcfz) left #scummvm.
[20:57] --> GitHub103 joined #scummvm.
[20:57] <GitHub103> [scummvm] bonki pushed 1 new commit to master: https://git.io/vxDts

[20:57] GitHub103 (GitHub103@gateway/service/github.com/x-omjlsmcvlxlgovhv) left #scummvm.
[21:01] <-- Farmboy0 left irc: Remote host closed the connection
[21:16] <-- LubomirR left irc: Quit: Leaving
[21:19] <rsn8887> How is configure different from just any other random shell script? How is anything in autotools standardized? Seems just like a bunch of scripts slapped together that do something else with every package...
[21:20] <rsn8887> It seems like the worst solution for a common installer
[21:20] <madmoose> rsn8887: Welcome to UNIX. Enjoy your stay.
[21:20] <_sev> indeed, welcome to UNIX
[21:21] <rsn8887> Is there even any documentation about what arguments configure should have? It seems different for every single package I try to install
[21:21] <rsn8887> It is really completely random
[21:21] <bonki> it's something that has grown historically with portability in mind. writing portable shell script is not as easy as it sounds which is why it looks like shite
[21:21] <bonki> that being said, it's crap nonetheless
[21:23] <bonki> configure (the file) is generated by autotools
[21:23] <bonki> based on the information you feed it, so it's quite logical that it differs between packages - that's the point of autotools ;-)
[21:24] <rsn8887> The only way to use configure is to look at the script itself and try to read the code, it really has zero usability.
[21:24] <bonki> why do you think so?
[21:25] <rsn8887> Because every time I try to install something I find myself looking at configure itself trying to understand why it is not working. Looking at it, it invokes the compiler a billion times to try to guess meaningful facts about the environment.
[21:27] <bonki> you are not meant to look at the generated code, that indeed is a noisy gibberish
[21:27] <bonki> -a
[21:27] <rsn8887> I mean on no other system do I have to look at the source code of an installer to make it work
[21:28] <bonki> also, you would look at the Makefile if you were trying to figure out what 'make uninstall' does behind the scenes. but yeah, I don't disagree
[21:29] <bonki> which is why I never ever install stuff by hand that way unless absolutely necessary
[21:29] <bonki> (Gentoo user here)
[21:30] <rsn8887> Nothing has ever seemed as ad-hoc as configure/make. It is as if theres no infrastructure enforced by the OS at all, so everything is just installing itself wherever etc.
[21:30] <bonki> well, you are supposed to tell it where to install
[21:31] <bonki> but indeed, that is why package management exists
[21:31] <bonki> so you should use that
[21:31] <rsn8887> Even the default dir names in linux: etc, bin sbin it is as if we are still in the eighties
[21:31] <rsn8887> Three letter names because they are faster to type?
[21:32] <rsn8887> And a lot of that stuff still seems hard coded in those configure files... places where it expects things etc I just dont know it is very frustrating
[21:32] <rsn8887> usr bin etc/bin where the heck are my apps?
[21:33] <rsn8887> I give up
[21:33] <rsn8887> Tomorrow it will all seem fine again but for today I have had enough unix
[21:33] <bonki> that's a whole different discussion, but if you don't like FHS then there are distributions which use a more modern filesystem hierarchy
[21:34] --> noobineer joined #scummvm.
[21:34] <rsn8887> It seems configure also uses environment variables a lot
[21:34] <bonki> as I said, the files you probably are looking at are auto-generated (hence the name "auto"tools), so they _are_ hardcoded :)
[21:34] <rsn8887> Which introduces so much state that it is impossible to debug
[21:35] <rsn8887> Yes
[21:35] <bonki> you are not supposed to debug those
[21:35] <bonki> it's as easy as that
[21:35] <bonki> it's pointless
[21:35] <bonki> you have to look at the input files, if at all
[21:36] <rsn8887> Auto tools are like templates in c++ useful but the generated code is way too hard to understand
[21:36] <bonki> you don't have to understand it
[21:36] <rsn8887> Ok so I should look at the .in files? Some projects have hundreds of those. Not even source code, just scripts to make it compile
[21:38] <rsn8887> Obviously I dont understand those either they seem to be more scripts that can do almost anything and look complete different between projects
[21:39] <rsn8887> It makes stuff unportable unless I port to a system that supports autotools which is only Unix
[21:40] <rsn8887> I guess cmake fixes this but only 20% of packages use it.
[21:40] <-- DJW|Home left irc: Read error: Connection reset by peer
[21:41] --> DJW|Home joined #scummvm.
[21:41] #scummvm: mode change '+o DJW|Home' by ChanServ!ChanServ@services.
[21:42] --> GitHub146 joined #scummvm.
[21:42] <GitHub146> [scummvm-tools] sev- pushed 1 new commit to master: https://git.io/vxDO9
[21:42] <GitHub146> scummvm-tools/master 4a61d92 Eugene Sandulenko: TOOLS: Fix extract_prince for individual files....
[21:42] GitHub146 (GitHub146@gateway/service/github.com/x-aegpgipjhsachlgo) left #scummvm.
[21:42] <bonki> there is autoconf (which generates 'configure') and automake (which generates Makefiles). typically, there's a Makefile.am which is written by hand. automake takes this as input, applies its magic and generates a Makefile.in. then, there's a configure.ac/.in which is also written by hand. autoconf takes this as input, applies its magic and generates 'configure'. when you run 'configure', it creates a
[21:42] <bonki> Makefile based on the earlier generated Makefile.in. when all that is done, that is what is being used when running 'make'
[21:43] <bonki> some projects only distribute the .in/.ac files and require you to run autoconf/automake and generate the resulting files yourself, others distribute the generated files so you don't have to generate them yourself
[21:44] <bonki> it's complicated and a mess but there are good reasons why it works exactly like it does
[21:44] --> Drenn joined #scummvm.
[21:44] --> GitHub75 joined #scummvm.
[21:44] <GitHub75> [scummvm-tools] sev- pushed 1 new commit to master: https://git.io/vxD3f
[21:44] <GitHub75> scummvm-tools/master be35045 Eugene Sandulenko: TOOLS: Fix memory leak
[21:44] GitHub75 (GitHub75@gateway/service/github.com/x-yppqfexbtdkywfcm) left #scummvm.
[21:45] <bonki> to*
[21:47] --> GitHub86 joined #scummvm.
[21:47] <GitHub86> [scummvm-tools] sev- pushed 1 new commit to master: https://git.io/vxD3E
[21:47] <GitHub86> scummvm-tools/master ca8502f Eugene Sandulenko: TOOLS: Remove unneeded free() calls
[21:47] GitHub86 (GitHub86@gateway/service/github.com/x-txjlbpndzibdyzlo) left #scummvm.
[21:51] <_sev> bonki: the only vable option in our case could be cmake
[21:51] <_sev> bonki: but so far nobody did it
[21:51] <bonki> the whole point of autotools is portability as it requires "only" a bourne shell, which is also why the generated code is ugly and slow and runs on a myriad of platforms which nobody uses anymore (probably)
[21:52] <bonki> if you were to drop the bourne requirement the code would be readable, compact and a lot faster
[21:52] <_sev> I knew about autotools for like 20 years
[21:52] <_sev> so far, our overcomplicated (now) configure does the job
[21:52] <_sev> it will be quite tricky to do the things we are doing now
[21:53] <_sev> like assembling compile dependencies from all engines
[21:53] <_sev> and declaring turnable subengines in them
[21:56] <bonki> I once wrote a proof-of-concept in POSIX-compliant shell which was only a few thousand LOC which could take CMake-like input files and generate both non-recursive or recursive Makefiles. the DSL was shell as well so it was dynamic and extensible on-the-fly. basically, CMake without the overhead of CMake, all the advantages of shell and a _lot_ faster than both autotools and CMake and portable as long as the
[21:56] <bonki> target platform had a POSIX-compliant shell
[21:57] <_sev> sounds something similar to our build system :P
[21:57] <bonki> not really ;-)
[21:57] --> girafe joined #scummvm.
[21:58] <bonki> I probably made it sound like that, though
[21:58] <bonki> heh
[21:58] <_sev> well, all of these initiatives come down to having a fully functional replacement written
[21:59] <_sev> and now we are talking about 5.5k lines of code
[21:59] <_sev> too much work for a little advantage
[21:59] <_sev> e.g. simple question: what problem are you trying to solve?
[22:00] <bonki> I agree. I've always been against custom build scripts but in our case I don't see the point in throwing away what we have, it's not that much code and it works well
[22:00] <_sev> indeed
[22:00] <_sev> and everybody knows it is not ideal
[22:00] <bonki> I'm not trying to solve a problem? I just explined to rsn8887 how autotools works
[22:00] <_sev> but Just Does the Job (TM)
[22:00] <bonki> I'm not planning on replacing our build system, neither did I criticize it
[22:01] <bonki> explained*
[22:01] <_sev> heh, somehow I missed the beginning of your discussion
[22:01] <bonki> seems like it :)
[22:02] <_sev> but anyway, it was nice to learn about your POC shell
[22:02] <_sev> our scummvm-tools strings stole 5 hours of my life today
[22:02] <_sev> very buggy thing
[22:02] <_sev> and I couldn't solve it :/
[22:03] <bonki> it was a nice little project at the time, never used it for anything, though
[22:03] <bonki> oops
[22:12] <rsn8887> The autotools generated configure script for libpng says on the top "Guess values for system-dependent variables and create Makefiles."
[22:12] <rsn8887> Just that itself.
[22:12] <rsn8887> My build script should not "guess" anythibg
[22:12] <rsn8887> either it knows for sure or it doesn't
[22:12] <rsn8887> for example, this scripts builds an executable, then tries to execute it, to see if "we are cross-compiling"
[22:13] <rsn8887> I can think of a thousand reasons why I might be cross-compiling but still the executable somehow does something on the host machine.
[22:13] <rsn8887> The whole system is just fragile
[22:13] <-- ny00123 left irc: Quit: Leaving
[22:14] <rsn8887> It seems to be completely immersed in the current state of the host machine, completely dependent on it to fail for a myriad possible readons, therefore, autotools, with the goal of portability, has reduced portability. IMO
[22:14] <rsn8887> reasons
[22:15] <bonki> you are missing the point
[22:15] <bonki> configure usually builds a lot of executables behind the scene to figure out ("guess") available features, i.e., actually checking how stuff works on the host
[22:15] <rsn8887> Another remark at the top "Be more Bourne compatible" either it is or it isn't bourne compatible. Even the language of autotools-generated comments rubs me the wrong way
[22:16] <bonki> and based on that make sure that the building process does exactly what it should
[22:16] <bonki> instead of actually "guessing"
[22:16] <rsn8887> bonki: which is nonsensical if I am building a windows executable on a linux machine for example.
[22:16] <bonki> it's actually the opposite
[22:16] <rsn8887> It shouldn't have to invoke the compiler at all until it is actually compiling my program
[22:16] <rsn8887> Running the compiler a thousand times to "guess" things in itself is a horrible idea.
[22:17] <rsn8887> My system state should be readable without running a thousand little test compilations. If an OS is not able to provide the state to my build-system, the OS is broken.
[22:18] <rsn8887> autotools is just a workaround for a broken system.
[22:18] <bonki> I'm sorry, but you are criticizing something you don't understand
[22:18] <rsn8887> Probably true.
[22:18] <bonki> not that I am trying to defend autotools
[22:19] <bonki> as I said, I don't like it either
[22:19] <bonki> but not for the reasons you mention
[22:19] <rsn8887> However when I see that the script is testing for a known buggy-behavior in a certain version of Zsh to find out whether it is running on that particular version of Zsh
[22:19] <rsn8887> instead of being able to just read out the version number, I get a headache.
[22:20] <bonki> that is by design. as I said earlier, it tests for actual behavior which imo is a good thing
[22:21] <rsn8887> It is testing for a subset of known bugs to make inferences about installed components.
[22:22] <bonki> which it has to do. it's not autotools' fault that applications which the build system uses are or can be buggy
[22:22] <rsn8887> It is gigantic workaround around hundreds of documented bugs.
[22:22] <bonki> more or less
[22:24] <Dark-Star> ...yet it doesn't even do a good job anymore at the one thing it was designed to do: run on as many systems as possible. If you have a non-gnu toolchain, or a slightly exotic BSD, autotools will fail in quite spectacular ways :)
[22:25] <rsn8887> It makes sense: It is handcrafted by checking all the known bugs in a few selected systems. So if let loose on a different environmen, it all goes out the window. It is not portable by any definition. Unless you take portable to mean "hand-tuned for every possible combination of known system components"
[22:26] <rsn8887> If I have components that just happen to have similar bugs, it will make wrong guesses about the actual environment.
[22:26] <Dark-Star> yet there simply is no other alternative as of now, especially for cross-compiling
[22:26] <bonki> it doesn't, because, obviously, it only checks those things which it needs for building your project. so it would check exactly the same things in a different environment, and it would have to
[22:27] <rsn8887> I have an example, I don't know if this fits:
[22:28] <bonki> and if your hand-crafted input files are written "properly" (which probably isn't easy) it shouldn't fail even on a slightly exotic BSD :-)
[22:28] <rsn8887> Say it is checking for device names with colons to decide whether we are using Windows-style fs (backslashes, device-colons) or unix style (slashes, no colons). BUt then Vita uses colons AND slashes.
[22:28] <rsn8887> So if it ran on Vita it would fail.
[22:29] <rsn8887> Or not, depending how the check is written.
[22:29] <Dark-Star> bonki: you might want to read this to see some of the crazier bugs that autotools' detection methods create: https://www.sigbus.info/software-compatibility-and-our-own-user-agent-problem.html
[22:29] <bonki> you are not running on the Vita, are you? you are cross-compiling
[22:29] <bonki> so that point is moot?
[22:29] <rsn8887> Instead of reading some kind of string that allows the filesystem itself to tell it what it is
[22:29] <rsn8887> It was a hypothetical example
[22:30] <bonki> but it's not a practical example, it's purely hypothetical as it probably isn't supported on the Vita
[22:30] <bonki> (I have no clue)
[22:30] <Dark-Star> "The problem that [on FreeBSD], [the lld linker] would be determined by configure as if it were an ancient Unix linker like 30 years ago. [....] Tthe configure script runs the linker [...] with the --help option, and determines it as a modern linker only when the displayed help message contains "GNU" or "with BFD"
[22:30] <bonki> Dark-Star: reading :)
[22:30] <rsn8887> So if it wants to know the filesystem, read the ID string and trust it, instead of meddling with the behavior.
[22:30] <Dark-Star> for autotools, everything that is not GNU must be >30 years old apparently :)
[22:33] <rsn8887> Nice.
[22:33] <bonki> Dark-Star: and that is why you don't do shit like that and check behavior instead
[22:33] <bonki> :)
[22:33] <bonki> so yeah, that is horribly broken
[22:34] <rsn8887> I would use the example to make the opposite point: ad-hoc kludged together tests to make "guesses" about the environment are not the way to go.
[22:35] <rsn8887> checking the --help string is checking behavior, checking the --version string would not be. But there is no standard --version counting, numbering whatever. Nothing is standardized and therefore everything is broken. More so in the unix world than in MacOS/Windows world actually.
[22:35] <bonki> wchecking a --help string is absolutely not checking any behavior, it's the total opposite
[22:35] <bonki> -w
[22:36] <rsn8887> it is running the program with some parameters and checking the output.
[22:36] <rsn8887> That is behavior
[22:36] <bonki> and any check doing so which could be written in a saner way is horribly broken, agreed
[22:37] <rsn8887> It is more amazing that anything actually works, with everything being buggy and depending on everything else.
[22:37] <rsn8887> and the bugs of everything else.
[22:37] <Dark-Star> problem is that nobody maintains configure scripts (or apparently, autotools checks) nowadays. They would need to be rewritten completely. But that still doesn't fix all the pre-configured "configure" scripts out there
[22:37] <bonki> exactly, --version is not standardized (you can't even rely on the parameter being present) so I don't understand how you can say that checking --help differs from checking --version
[22:38] <bonki> the only difference is that checking --version is, in many cases, probably a lot less errorprone, but one thing cannot replace the other because the information provided is not the same
[22:38] <bonki> Dark-Star: I concur
[22:38] <Dark-Star> I guess we will, in the future, see more containerized build systems that come with the correct prerequisites and only a minimal configure script for enabling/disabling features
[22:40] <Dark-Star> that would just require a simple "alias scummvm-make=docker run ..." with the correct parameters to map the current directory (source code) into the container and run the build system there
[22:41] <bonki> the problem is portability is a pain, no matter on which level. doing things the right way is hard and requires experience no matter which tools you use. the tools should make it as easy as possible, and autotools horribly fail at that because they are from the stone-age. cmake is a lot better but it's still hard
[22:41] <Dark-Star> cmake is great for local builds but it is still lacking in the cross-building department
[22:41] <bonki> but in the end it all depends on your definition of "portable"
[22:46] <bonki> rsn8887: btw, it is not configure's fault that it is running dozens of checks and "guessing" stuff, because it doesn't do anything on its own. autotools are just a framework, someone made your configure script do those things to achieve a certain goal. so you should not complain about autotools but to the developer of the project you are trying to build if you believe that some checks are wrong or
[22:46] <bonki> unnecessary
[22:46] <rsn8887> Cmake is definitely a more modern, more "standard" approach, I just wish there was better documentation of all commands and variables etc for cmake.
[22:47] <rsn8887> for example in cmake I can do cmake -DCMAKE_BUILD_TYPE=Release or -DCMAKE_BUILD_TYPE=Debug those are standardized in a sense
[22:47] <Dark-Star> SCons is also a good tool, but it lost the race against CMake because back then it was written in Scheme and nobody liked Scheme except me apparently :) (also it was slooooow). Not it's in Python (bad for me as I know less Python than I know Scheme) but apparently it's gotten a lot faster in the process... still almost zero adoption rate apparently ...
[22:51] <rsn8887> I also like that cmake has a standard ui, ccmake. However it is still not exacty easy to understand or use.
[22:53] <-- ced117 left irc: Ping timeout: 256 seconds
[22:53] <Dark-Star> I saw the GUI once but it was just a more fancy way of editing cmake variables back then and I wondered why anyone would need this... if you want to know what variables you can set to influence the build, it is usually faster to just look at the CMakeLists.txt file. And once you got them, running from the command line is again faster as it involves less clicking
[22:54] <Dark-Star> it can probably help if you'Re just getting started with cmake, but as soon as you know all the variables like CMAKE_BUILD_TYPE etc. you don't need it anymore I think
[22:55] --> ced117 joined #scummvm.
[22:56] <Dark-Star> (and there are good cmake tab completion scripts for most shells available as well ;-)
[23:01] <rsn8887> Dark-Star: it is nice for a noob and allows cycling through possible variable values I think.
[23:01] <rsn8887> and of course shows all the variables
[23:01] <rsn8887> and help strings for each
[23:08] --> Cheeseness joined #scummvm.
[23:15] <rsn8887> btw: is there any rhyme or reason to the sorting of arguments in man pages? It is certainly not alphabetical.
[23:36] <-- criezy left irc: Quit: criezy
[23:45] <-- noobineer left irc: Ping timeout: 240 seconds
[00:00] --- Thu Apr 5 2018