| 00:01.07 | blast007 | "GNU libtool is a generic library support script. Libtool hides the complexity of using shared libraries behind a consistent, portable interface." |
| 00:10.00 | macsforme | so perhaps to make it work better cross-platform |
| 00:10.09 | macsforme | I know brlcad was a BSD guy :) |
| 00:10.22 | JeffM | and an OSX guy |
| 00:30.21 | *** join/#bzflag Shuist (~Shuist@ppp203-122-213-220.static.internode.on.net) |
| 00:47.29 | Delusional | very interesting link up there |
| 01:24.22 | *** join/#bzflag echelon (~echelon@bzflag/player/echelon) |
| 01:24.26 | echelon | howdy |
| 01:24.34 | echelon | is Constitution around? |
| 01:24.41 | macsforme | howdy |
| 01:24.53 | macsforme | oh, I'm Constitution :P |
| 01:29.22 | macsforme | may I help you? |
| 01:30.12 | echelon | macsforme: cool, i'm titmouse :) |
| 01:30.30 | echelon | i was gonna send you my drawing of that map i was trying to remember |
| 01:31.13 | macsforme | ah yeah |
| 01:37.43 | echelon | macsforme: so the bottom pic is what it looks like from the center of the map.. http://imgur.com/a/vzoVT |
| 01:38.06 | echelon | and the top is what the base looks like on each side |
| 01:38.37 | macsforme | boxy war? |
| 01:38.55 | blast007 | was it a two team CTF? could be the Zigurat server/map. |
| 01:39.10 | echelon | i think it's boxy war :D |
| 01:39.41 | echelon | anyone running it atm? |
| 01:42.03 | macsforme | was it this one? http://imgur.com/a/Ug12N |
| 01:42.18 | echelon | yeah, that's the one! :) |
| 01:42.30 | echelon | thanks |
| 01:43.04 | macsforme | np... I know there were several versions of it... I think when BZFX ran it the middle was different |
| 01:43.19 | echelon | oh |
| 01:44.01 | echelon | not as cool as the compound, but it was fun |
| 01:46.20 | echelon | there was two ways to enter, either from the sides or through the front pyramids |
| 01:46.44 | echelon | or with oscillation :P |
| 02:24.00 | BulletCatcher | IIRC there was some unresolved dispute over the ownership of the Boxy Wars map. |
| 02:24.01 | BulletCatcher | It was never openly released, and I doubt we'll see it again. |
| 02:30.56 | echelon | yikes |
| 02:32.59 | macsforme | there is this (apparently old) version released under the GPL: https://forums.bzflag.org/viewtopic.php?f=64&t=14039&p=137721 |
| 02:33.24 | macsforme | I think it was the updated version that had the licensing dispute |
| 04:01.21 | *** join/#bzflag a_meteorite (~a_meteori@unaffiliated/ameteorite/x-000000001) |
| 05:08.31 | allejo | blast007, got any info on client version usage for the server list? |
| 07:00.20 | *** join/#bzflag a_meteorite (~a_meteori@unaffiliated/ameteorite/x-000000001) |
| 07:55.23 | allejo | macsforme, is your premake work close enough to being done that my PR is gonna cause you merge conflicts? i'm thinking about my changes to the Xcode project file |
| 07:59.09 | macsforme | I'm typing the PR as we speak |
| 07:59.32 | macsforme | but yours will get merged in first I'm sure, so don't worry about it... I'll rebase |
| 08:30.50 | allejo | ah sounds good |
| 09:23.21 | *** join/#bzflag the_map (~the_map@unaffiliated/the-map/x-1795707) |
| 11:15.31 | blast007 | the premake stuff is for 2.6 right? |
| 13:10.17 | *** join/#bzflag tupone (~alfredo@gentoo/developer/tupone) |
| 15:48.29 | allejo | having it for 2.4 would be nice too |
| 15:48.56 | blast007 | why? |
| 15:49.45 | allejo | cuz it'd make my life easier with plugins |
| 15:50.22 | blast007 | barely |
| 15:50.55 | blast007 | our configure script already makes that easy |
| 15:51.11 | allejo | not for macOS |
| 15:51.36 | blast007 | so leave Windows and autotools alone and do it for macOS |
| 15:55.32 | allejo | i'd have no objections to that |
| 15:58.12 | BulletCatcher | Assuming that premake doesn't cause incompatible changes to the network protocol or gameplay, and we really do want to use it, then there is no reason not to use it in 2.4. |
| 15:58.14 | BulletCatcher | Since it *is* a nontrivial change for developers, it makes sense to me to roll it out first for macOS and then consider whether to do so for other platforms. |
| 15:59.10 | blast007 | premake is also not packaged in Debian Wheezy, but is in Jessie |
| 15:59.19 | blast007 | so depends if we want to support the current 'oldstable' |
| 15:59.59 | blast007 | or wait, I guess it is |
| 16:00.10 | allejo | :D |
| 16:00.11 | blast007 | package name changed from premake to premake4 |
| 16:00.21 | blast007 | what version of premake does it require? |
| 16:01.41 | BulletCatcher | If we want to, we can modify autogen.sh to use premake when it is available and autotools when it is not. |
| 16:02.31 | blast007 | does premake generate a configure script? |
| 16:06.21 | *** join/#bzflag a_meteorite (~a_meteori@unaffiliated/ameteorite/x-000000001) |
| 16:09.19 | *** join/#bzflag a_meteor_ (~a_meteori@unaffiliated/ameteorite/x-000000001) |
| 16:12.32 | *** join/#bzflag a_meteorite (~a_meteori@unaffiliated/ameteorite/x-000000001) |
| 16:15.08 | *** join/#bzflag a_meteor_ (~a_meteori@unaffiliated/ameteorite/x-000000001) |
| 16:18.08 | *** join/#bzflag a_meteorite (~a_meteori@unaffiliated/ameteorite/x-000000001) |
| 16:20.40 | *** join/#bzflag a_meteor_ (~a_meteori@unaffiliated/ameteorite/x-000000001) |
| 17:34.02 | *** join/#bzflag KaadmY (uid135503@gateway/web/irccloud.com/x-fhfixtikwopomohv) |
| 18:02.13 | *** join/#bzflag a_meteorite (~a_meteori@unaffiliated/ameteorite/x-000000001) |
| 18:10.09 | *** join/#bzflag echelon_ (~echelon@bzflag/player/echelon) |
| 18:16.23 | macsforme | the main benefit of premake is only realized if we use it for all platforms we support... otherwise we just have one additional set of project scripts to maintain (or at best, the same number, if we only deploy it for one platform) |
| 18:17.27 | macsforme | *cue blast007 posting the XKCD comic about creating one universal standard* |
| 18:20.20 | macsforme | it uses premake5, which was necessary because of a new feature that allows custom Xcode project settings (like our deployment target, C++11 language dialect, etc.) |
| 18:21.41 | blast007 | okay, so it can't be used on Debian then.. |
| 18:21.46 | macsforme | premake5 is still in alpha, so it is unlikely to be in the linux distros at this point... we would probably be looking at some changes involving linux |
| 18:22.13 | macsforme | it can, it's just not available from their repository |
| 18:22.28 | blast007 | so, it's going to be for BZFlag 2.8 then ;) |
| 18:24.35 | blast007 | you're not actaully expecting it to go into 2.4, right? |
| 18:26.28 | macsforme | let me finish writing up the PR, and then we can discuss any concerns that arise... I will do everything I can to make it work for everyone |
| 18:27.08 | macsforme | but yes, the goal would be to merge it into the branch that development is happening on, not to have it sit on its own waiting for a future release that will probably never happen |
| 18:27.23 | KaadmY | https://xkcd.com/927/ |
| 18:27.58 | macsforme | slaps KaadmY |
| 18:28.04 | KaadmY | slaps XKCD |
| 18:32.08 | macsforme | it should not in any way "cause incompatible changes to the network protocol or gameplay" |
| 18:40.14 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 18:50.18 | *** join/#bzflag TimRiker (~TimRiker@bzflag/projectlead/TimRiker) |
| 18:50.18 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 19:19.17 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 19:45.21 | TimRiker | JeffM, responded in email. #bzflag-chat is now setup where you can edit the access list. |
| 19:46.27 | JeffM | TimRiker: thanks, I'll look at it after I fix a busted build automation app :( |
| 19:46.40 | JeffM | And find time to eat |
| 19:55.33 | TimRiker | :) |
| 20:03.38 | *** join/#bzflag a_meteorite (~a_meteori@unaffiliated/ameteorite/x-000000001) |
| 20:13.04 | *** join/#bzflag a_meteorite (~a_meteori@unaffiliated/ameteorite/x-000000001) |
| 20:13.42 | *** join/#bzflag Gnurdux (~Michael@c-73-149-20-29.hsd1.ma.comcast.net) |
| 20:28.49 | JeffM | yay, it's not one of my cards in this house of cards that is broken, time to pass the blame :) |
| 20:29.02 | macsforme | you spell my last name in a very interesting way, JeffM ;-) at least you spell it the way it sounds (kinda) |
| 20:29.14 | JeffM | gmail did that |
| 20:29.17 | JeffM | or maybe I did |
| 20:29.32 | JeffM | there are multiple joshes in my address book |
| 20:30.44 | *** join/#bzflag BZnotify (~BZnotify@192.30.252.34) |
| 20:30.44 | BZnotify | [13bzflag] 15macsforme opened pull request #62: premake build system (062.4...06premake) 02https://git.io/vMp6F |
| 20:30.44 | *** part/#bzflag BZnotify (~BZnotify@192.30.252.34) |
| 20:33.09 | macsforme | I need as many people as possible to try that out, please... it's a big change so I need to know if any issues arise on any of our platforms, no matter how significant |
| 20:33.51 | JeffM | where does it look for the dependencies on windows? |
| 20:34.30 | macsforme | it reads the BZ_DEPS environmental variable for the location, just like before |
| 20:35.47 | blast007 | what do we do for platforms that don't provide premake5? |
| 20:36.08 | JeffM | the healing power of prayer |
| 20:36.26 | macsforme | premake supports Windows, macOS, Linux, Solaris, BSD, and some others |
| 20:36.27 | blast007 | the soonest Debian will is probably 2019, assuming premake5 is stable enough for them by that time |
| 20:37.12 | blast007 | and Debian Stretch will be supported until 2020 |
| 20:37.34 | blast007 | and the current Ubuntu LTS (16.04) is supported until 2021 |
| 20:39.51 | macsforme | people who need to compile development code can download a Linux binary for premake5 from GitHub |
| 20:40.42 | blast007 | uh, but what about being packaged for linux distros? |
| 20:41.17 | blast007 | it's unfortunate you didn't think about any of this |
| 20:41.40 | JeffM | he means that bzflag wold have a dependency that debian would not be able to meet, so you could not have a release unitll premake5 was in the same version of debian |
| 20:41.50 | macsforme | I would have to learn more about that process to be able to give an educated answer |
| 20:42.05 | JeffM | it's like a required library |
| 20:42.06 | macsforme | and actually I did think about it, if you read the PR in full |
| 20:42.35 | JeffM | imagine if debian didn't incldue SDL2 and there was no option to build with SDL1 |
| 20:42.37 | blast007 | I mean before you started any of this |
| 20:43.38 | JeffM | I only see mention of package creation, not dependencies in the PR |
| 20:43.47 | macsforme | we can build autotools scripts using premake |
| 20:44.31 | blast007 | and we'd check those in to git? |
| 20:44.31 | JeffM | so the packaging process would require premake to build the autotools scripts then the package that is created is configured to use autotools instead of premake? |
| 20:45.21 | JeffM | if you ever wanted debian clean to be able to build your package, you'd have to check those in, or install an external premake |
| 20:45.40 | macsforme | I think that would work... there are just some limits to the autotools scripts currently |
| 20:45.44 | JeffM | so like a build farm or osmething could be dificut if you don't check them in |
| 20:46.02 | JeffM | if the autotools are checked in, what are you saving? |
| 20:46.13 | JeffM | just more features for the platforms that can use automake? |
| 20:46.53 | JeffM | I understand that debian is not a major platform, but it does sound like this would add some special cases to it |
| 20:47.02 | blast007 | it is |
| 20:47.03 | JeffM | you just want to make sure your special cases are reasonable |
| 20:47.24 | blast007 | a large number of distributions are based on Debian |
| 20:47.33 | blast007 | if it isn't in Debian, it likely won't be in those either |
| 20:47.35 | JeffM | true |
| 20:47.42 | blast007 | Gentoo doesn't have it |
| 20:47.47 | macsforme | we wouldn't check the autotools scripts in to git... but if we needed to make a .deb or .rpm, we could generate the scripts and then that gives us a place to start |
| 20:47.51 | blast007 | Arch only has it in their user repository |
| 20:48.13 | JeffM | macsforme: can you automate that? |
| 20:48.29 | macsforme | I think so... again, I need to educate myself more about that process |
| 20:48.30 | JeffM | and is debian ok with the package having files that arn't in source? |
| 20:48.44 | blast007 | Debian pulls from our git |
| 20:48.56 | JeffM | they do the package build right? not us? |
| 20:48.58 | blast007 | hmm, or maybe our source tar |
| 20:49.12 | blast007 | I'm not sure how they do it now that we're in github |
| 20:49.25 | JeffM | lazers |
| 20:49.58 | macsforme | or as I mentioned in the PR, we could start going the container route on Linux, and avoid the ongoing release timing/update issues altogether |
| 20:50.05 | macsforme | it's something we could evaluate |
| 20:50.26 | JeffM | I'd think that'd be a seperate issue from the build system, but yes worth discussing |
| 20:53.11 | macsforme | yes, although they are linked in a way, if the benefits of using premake push us in that direction |
| 20:53.27 | JeffM | well they do work well together, but they are not strongly dependent |
| 20:53.36 | JeffM | one just makes things in the other easier |
| 20:53.50 | JeffM | you can state that as a benift, but it is not a hard requrement |
| 20:55.22 | blast007 | "container approach" meaning what? |
| 20:56.28 | blast007 | pretty sure Debian wants it to be able to build in Debian, not in "specialized container environment that builds extra stuff" |
| 20:56.34 | macsforme | docker, snaps, etc. |
| 20:57.23 | blast007 | no |
| 20:58.08 | blast007 | you're making the build system more complicated than the game itself :P |
| 20:58.27 | JeffM | wispers THATS WHY THEY ARE NOT STRONGLY RELATED ;) |
| 21:00.07 | JeffM | docker your ideas |
| 21:12.31 | macsforme | just one of those technologies, not all... |
| 21:13.29 | macsforme | building one snap container is simpler, for instance, than creating separate packages/scripts for debian, fedora, gentoo, etc. |
| 21:14.28 | blast007 | I know just one |
| 21:15.12 | blast007 | so you're suggesting we stop packaging for Debian |
| 21:18.03 | macsforme | I'm saying packaging via container rather than individual distro packages is one option to be considered when we're looking at how the premake system should interact with the linux packaging process |
| 21:19.08 | blast007 | which would mean we don't package for Debian |
| 21:19.57 | JeffM | I don't belive debian packages can be containers, they are bins they build from sources |
| 21:20.07 | JeffM | they are very old school that way |
| 21:20.22 | blast007 | I'm going to assume that *most* distros are that way |
| 21:20.28 | JeffM | ues |
| 21:20.30 | JeffM | yes |
| 21:20.38 | JeffM | maybe some server centric ones arn't |
| 21:20.45 | blast007 | even those |
| 21:20.49 | JeffM | but the desktop ones will be for sure |
| 21:21.09 | blast007 | unless you're talking about something like CoreOS, which isn't where we care about running |
| 21:21.24 | JeffM | yes, those kind of cloudish wishy washy thing |
| 21:21.35 | JeffM | it's not something a gaming user or hoster will use |
| 21:22.14 | macsforme | users would install snapd and then browse the snap repository to find us |
| 21:22.44 | JeffM | so we would not package for debian |
| 21:22.50 | blast007 | E: Unable to locate package snapd |
| 21:23.02 | JeffM | they would use a third party repository |
| 21:23.39 | blast007 | https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_FrankenDebian |
| 21:32.04 | *** join/#bzflag a_meteorite (~a_meteori@unaffiliated/ameteorite/x-000000001) |
| 22:22.34 | JeffM | done day I'd still like to have a conversation with someone from debian about what the expected release-flow for a MMO style game would be on debian-like systems. |
| 22:22.43 | JeffM | some day even |
| 22:23.22 | JeffM | given a set up update requirements, how would they suggest it be handled. |
| 23:03.07 | *** join/#bzflag echelon (~echelon@bzflag/player/echelon) |