| 00:09.21 | macsforme | tupone: ah, I hadn't heard of that until now... I could probably implement that pretty easily, but to my knowledge there's no built-in support for that |
| 00:11.41 | macsforme | I am pondering how to move forward with linux packaging... as far as I can tell, there's no way to create a "make [un]install" action, only custom premake actions, which means at some point compiling and installation will require premake... I'm trying to figure out a way around that since most distros don't include premake 5 currently |
| 00:14.56 | allejo | macsforme, for your premake work, is it possible to have a simple patch for macOS only that I can apply locally or is it very dependent on a lot of things and i'll always face conflicts? |
| 00:16.22 | macsforme | like to patch it in on top of trunk code temporarily? |
| 00:17.25 | allejo | yea |
| 00:18.23 | allejo | just curious if it's possible so i can just dump it on top of latest 2.4 whenever i'm working on stuff |
| 00:18.57 | blast007 | funny, that's what I want as well. a premake patch for just macOS. ;) |
| 00:19.06 | macsforme | well, some things in the source files were changed too... for example, premake detects the compiler and version, and defines the bzflag minor/minor/revision versions, and defines everything that was in config.h |
| 00:20.24 | allejo | hmm |
| 00:20.30 | macsforme | I am trying to resolve the outstanding concerns about the premake system so that it will be acceptable for all platforms |
| 00:21.35 | macsforme | if that ends up being unfeasable at the present time, then I will look at making it self-contained instead (however, this defeats almost all of the benefits) |
| 00:22.28 | blast007 | it's just gonna make more work for me since I assume a 'git clean -x -f -d' is gonna require re-running premake instead of just relaunching the .sln and hitting build |
| 00:26.07 | macsforme | blast007: I hope you will at least try it and play around with it a bit before you pass judgement... I think you will ultimately be impressed |
| 00:28.25 | macsforme | also, periodically running one console command to rebuild the project files is far less effort than manually keeping project files in sync across platforms as files move around, not to mention all your effort this last weekend to migrate the VS projects to another version (which, again, would have taken one console command, plus fixing any source file issues which you have to do anyway) |
| 00:29.37 | blast007 | We migrated from 2010 to 2015. So, not something we do all that often. |
| 00:30.58 | blast007 | and at this point, we don't even know that premake can do all what I did. One of your possibilities is just leaving prebuilt .sln files in the repo. |
| 00:31.34 | blast007 | upgrading the project files was easy. just opened the .sln and clicked ok. the .sln files were what had the extra step. |
| 00:32.03 | blast007 | (and even then, technically a multi-line find and replace could have upgraded those) |
| 00:35.38 | JeffM | macsforme: I was impressed by the fact that it actually worked, many other build systems don't work on windows, so it's not a super high bar for premake to pass. The resultant files did not look like ones I'd want to do day to day work in, they had too much of a lowest common denominator feel that replaced what I had with something worse. as for the updates, |
| 00:35.38 | JeffM | that for me when I did it, was not super hard to do. Nothing about it made me feel warm and fuzzy. Even on linux the fact that it wasn't packaged was bit of a pain. |
| 00:36.00 | JeffM | just giving you my honest opinion. |
| 00:37.01 | JeffM | I like the concept of a build tool for all systems, I'm must not sure if these sacrifices are worth the benefit. It feels like it's just shuffling the work around to different places, there isn't less of it, it's just different now. |
| 00:38.21 | JeffM | I mean if you want to force everyone to use the same style of builds, even if it's not what people on the OS are used do, build everything with mingw. it's consistent :) |
| 00:38.25 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 00:38.41 | macsforme | that's fair... but what I'm perceiving is that some of you would rather reject the system on its face than be willing to have an open mind and help me bring it up to expectations on Windows (my least familiar platform) |
| 00:38.56 | JeffM | VC is a very powerfull tool, one reason I think ti's the best IDE out there on any platform, and your setup minimized a lot of it's functionality for the sake of consistency. |
| 00:39.32 | JeffM | I'm worried about maintenance of the script if it gets too complicated |
| 00:39.42 | JeffM | basicly you'd be the one maintaining it |
| 00:39.47 | JeffM | and you don't use windows that often |
| 00:40.01 | JeffM | so now a non windows developer is in charge of making the windows build system windowsy |
| 00:40.31 | JeffM | where as now, those that do use windows can just change the windows build files on there own and not risk breaking other platforms. |
| 00:41.02 | JeffM | I underatnd your point thogh, I just dont' know enough about premake to know what is and isn't possible and some of your comments have not filled me with confidence. |
| 00:44.18 | macsforme | one of the main benefits of using premake is that the "maintenance" burden is tremendously reduced... and where changes will need to be made, the syntax is clear and straightforward |
| 00:46.44 | macsforme | so anyway, I am trying to come up with solutions... I just need people to have an open mind |
| 00:48.58 | macsforme | I am very new to premake also, so I may not have immediate answers/solutions |
| 00:51.34 | JeffM | you are thinkin of the burden of adding bzflag files, I am thinking of the burden of customizing it to meet each platform's optimal setup |
| 00:52.00 | JeffM | I'd also wonder if other systems should be at least evaluated, before all the work is done |
| 00:54.17 | blast007 | where did the m4 files go? |
| 00:54.52 | macsforme | away |
| 00:55.40 | blast007 | so does premake figure out what options libcurl was built with? |
| 00:56.41 | macsforme | there is no more config.h |
| 00:57.09 | blast007 | that not what I asked, though |
| 00:58.26 | blast007 | because it looks like you're just making assuptions and hardcoding defines that were previously detected by the various m4 files |
| 00:58.33 | macsforme | it doesn't... we would require a libcurl that is built with the features enabled that we utilize |
| 00:58.58 | blast007 | but you'd build it with one that doesn't have the necessary features with no warning to the user |
| 01:01.47 | macsforme | and that would compile and link? |
| 01:02.24 | blast007 | if curl doesn't have HTTPS support, I would think it would still compile and link, yes. It would just fail at runtime when we feed it an https:// URL |
| 01:03.55 | blast007 | now, we currently *don't* check for that in the code, but we *can* with our current autotools system |
| 01:04.10 | blast007 | s/in the code/in the autotools system/ |
| 01:05.43 | macsforme | yeah, those macros aren't even used by our code... none of them are |
| 01:07.17 | macsforme | furthermore, mac and windows already had static config.h files, so we would never have been able to support that fully as an optional feature |
| 01:07.53 | blast007 | on Windows we have control of the dependencies build |
| 01:08.19 | blast007 | on macOS it's also going to be more predictable because there's only gonna be one or two sources for binary packages of them |
| 01:08.28 | blast007 | Linux is a whole different ballgame |
| 01:14.31 | blast007 | it doesn't even detect if you have a working SDL2 or SDL1.2 |
| 01:14.57 | blast007 | it makes the user tell it to use one or the other (or neither) and then just assumes that all is well? |
| 01:15.57 | blast007 | So, before I looked at it closely, I was against it. Now that I'm looking at it closely, I'm VERY much against it. It's going to put the linux build system back into the stone ages. |
| 01:18.26 | macsforme | it doesn't "detect" what's installed on your system because you can generate the scripts on one system and then use them to build on another... it's a change from the autotools paradigm |
| 01:19.19 | blast007 | that doesn't seem like an advantage |
| 01:19.36 | blast007 | right now I don't need to generate anything on Windows. I just open a file and hit a button. |
| 01:24.52 | blast007 | I don't get why the ability to generate build files on a different OS is even a notable feature |
| 01:35.09 | macsforme | system library detection scripts do exist for premake... I think trepan had some in his premake4 system that was in 2.99 |
| 01:36.26 | macsforme | but that is really beyond the scope of what premake is supposed to do, for the reason I mentioned above |
| 01:44.03 | blast007 | "But but but, look, it has this feature that nobody wants or needs, so that makes up for loss of real functionality that people use right now" |
| 01:45.15 | blast007 | Why would I need to build OSX or Linux build file on Windows? |
| 01:45.19 | blast007 | files* |
| 01:46.56 | macsforme | I didn't suggest that... "system" meant a physical system, not an operating system |
| 01:47.59 | macsforme | however, the generation of scripts for another OS is also possible, at least on some operating systems |
| 01:48.23 | blast007 | the only reason I can think that you'd need to run premake on a system other than the one you're building on is because the build system doesn't have premake available - and guess what also solves that dilemma? |
| 02:04.49 | macsforme | so it appears the libcurl error is indeed at runtime when you link to a libcurl without SSL support |
| 02:07.34 | macsforme | although we have that same problem already in the current code |
| 02:08.04 | macsforme | and I don't see a libcurl package in debian that doesn't support SSL... did you have a specific distro in mind where that could be a problem? |
| 02:12.40 | blast007 | I'm sure most distributions would have SSL enabled libcurl. |
| 02:13.55 | blast007 | but another example would be IPv6 support for later |
| 02:14.54 | blast007 | hmm, SRV records are hostnames though, right? |
| 02:15.24 | blast007 | so I guess that might not matter |
| 02:15.47 | blast007 | I do not like that it doesn't automatically figure out what SDL version to use though |
| 02:16.31 | macsforme | I thought we are ultimately moving toward SDL2 as an outright dependency |
| 02:16.57 | macsforme | once the fedora issues are sorted out |
| 02:17.57 | blast007 | yeah, in several *years*, when every platform we care about has a new enough SDL2 |
| 02:19.14 | blast007 | Debian Jessie doesn't have a new enough SDL2, and that's supported until 2020 |
| 02:37.00 | macsforme | debian jessie also has BZFlag 2.4.2... if we're not going to get a bz release into a linux distro version, do we need to be concerned about whether it supports our dependencies? |
| 02:54.03 | blast007 | BZFlag 2.4.4, released Feb 14, 2016. Debian Jessie, released April 25, 2015. So why would they have anything other than 2.4.2 in their release? |
| 02:55.56 | blast007 | With very few exceptions, Debian (and many linux distributions) do not push updated versions of software into their released distributions. |
| 02:56.23 | blast007 | They wait until the next major release to push new versions. |
| 02:56.37 | blast007 | So, Debian Stretch will have 2.4.8. |
| 03:28.37 | macsforme | again, if no newer versions of bzflag are going into debian jessie, I don't see why we need to be concerned about whether debian jessie has a new enough SDL 2 for us going forward or not |
| 04:11.49 | macsforme | are we going to close the PR in bzflag-dependencies for VS2015 support? |
| 04:36.02 | macsforme | ah ha: https://github.com/premake/premake-core/wiki/vpaths |
| 04:42.34 | macsforme | JeffM: does that look like it will do what you want? |
| 05:41.52 | *** join/#bzflag Shuist (~Shuist@ppp203-122-213-220.static.internode.on.net) |
| 07:32.19 | *** join/#bzflag [dmp] (~dennis@unaffiliated/dmp/x-546784) |
| 08:21.19 | *** join/#bzflag a_meteorite (~a_meteori@unaffiliated/ameteorite/x-000000001) |
| 14:02.48 | *** join/#bzflag [dmp] (~dennis@unaffiliated/dmp/x-546784) |
| 14:17.44 | *** join/#bzflag Shuist (~Shuist@ppp203-122-213-220.static.internode.on.net) |
| 15:58.59 | *** join/#bzflag BZnotify (~BZnotify@192.30.252.42) |
| 15:58.59 | BZnotify | [13bzflag] 15blast007 pushed 1 new commit to 062.4: 02https://git.io/vDtmd |
| 15:58.59 | BZnotify | 13bzflag/062.4 14ec02007 15Scott Wichser: Rename loadSwearList function to loadBadwordsList for consistency. |
| 15:58.59 | *** part/#bzflag BZnotify (~BZnotify@192.30.252.42) |
| 16:43.31 | JeffM | macsforme: that's a script function, I can not tell from that document what it does in visual studio, but it sounds like it may do something similar |
| 17:08.57 | JeffM | blast007: macsforme BulletCatcher I think there is value in having a discussion and making a solid choice on if inclusion in current and future debian systems is a requirement for the project. The outcome of that choice will guide some aspects of development, not only how things are packaged but what libs are used. |
| 17:09.56 | JeffM | there are reasons for and against, and I think they should be weighed, and discussed, but in the end there needs to be a choice made |
| 17:17.50 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 17:18.18 | *** join/#bzflag a_meteorite (~a_meteori@unaffiliated/ameteorite/x-000000001) |
| 17:32.45 | Notify | 03BZFlag:Zehra * 9345 /Getting_Help: update |
| 17:34.17 | Zehra | the copyrighted could be updated in the main page |
| 17:34.24 | Zehra | http://bzflag.org/ |
| 17:34.31 | Zehra | to 2017 |
| 17:34.52 | Zehra | btw there's a typo on http://bzflag.org/help |
| 17:35.07 | Zehra | on futher support |
| 17:35.17 | Zehra | further* |
| 17:35.52 | Zehra | it says the project maintains a issue tracker |
| 17:36.02 | Zehra | should be an issue tracker |
| 17:36.05 | JeffM | it does |
| 17:36.09 | JeffM | in github |
| 17:36.47 | Zehra | wouldn't it be an issue tracker, instead of a issue tracker |
| 17:37.08 | Zehra | for proper english |
| 17:37.21 | JeffM | english is overrated |
| 17:37.34 | JeffM | tis the language of terrorism |
| 17:38.29 | Zehra | supports changing the main page to a different language |
| 17:38.50 | JeffM | welsh |
| 17:39.04 | JeffM | nothing bad ever happens in wales |
| 17:39.09 | JeffM | and if it does nobody reports on it |
| 17:40.11 | blast007 | I don't *have* to update the copyright date every year, ya know |
| 17:40.57 | Zehra | well it would be nice though :P |
| 17:41.02 | blast007 | why? |
| 17:41.49 | tupone | macsforme: an example - you expect to have the datafiles of bzflag on a configurable directory (/usr/share/bzflag/data for instance) and you use --prefix or datadir to tell the software to go there and pickup it. But you install all the tree in another directory. It won't work there, only it will be ready to be picked up to put in the real directory after |
| 17:42.22 | tupone | hope this use case is clear :( |
| 17:42.27 | Zehra | i think it shows that things are kept up to date |
| 17:43.49 | Zehra | i'm probably missing the big picture here |
| 17:45.02 | blast007 | Zehra: I'll worry about that when I migrate to the new website build process |
| 17:45.42 | Zehra | ok |
| 17:45.59 | Zehra | will be looking forward to it :) |
| 17:46.03 | blast007 | but first I figure we'll get 2.4.10 out, and I'll finish my new hosting configuration. |
| 17:46.36 | Zehra | nice |
| 17:56.04 | Notify | 03BZFlag:Zehra * 9346 /GroundMaterial: improved display of content |
| 18:01.14 | Notify | 03BZFlag:Zehra * 9347 /Map_making: /* Map Objects */ added object |
| 18:06.01 | Zehra | one quick thing about bz_setPlayerLosses |
| 18:06.40 | Zehra | does it work in the current API? |
| 18:07.13 | Zehra | 2.4.x? if i'm not mistaken |
| 18:08.03 | blast007 | check the bzfsAPI.h file |
| 18:08.20 | blast007 | include/bzfsAPI.h in the source |
| 18:09.50 | allejo | yea, it's a 2.4.x call |
| 18:11.11 | Zehra | ty allejo |
| 18:12.12 | Notify | 03BZFlag:Zehra * 9348 /Bz_setPlayerLosses: update |
| 18:12.46 | Zehra | it was saying before it was for 2.99 :P |
| 18:48.19 | blast007 | which wasn't untrue |
| 18:52.20 | Notify | 03BZFlag:Zehra * 9349 /Plug-ins: /* Standard plug-ins */ added link |
| 18:52.33 | Zehra | oops |
| 18:54.00 | Zehra | it said it was the minimum required version in the API to work |
| 19:16.52 | *** join/#bzflag KaadmY (uid135503@gateway/web/irccloud.com/x-ipvshssildnkgpgz) |
| 21:01.24 | *** join/#bzflag [Gort] (~gort@82-69-126-225.dsl.in-addr.zen.co.uk) |
| 21:01.24 | *** join/#bzflag [Gort] (~gort@unaffiliated/gort/x-9231432) |
| 21:22.11 | blast007 | I need to update the README.Windows for Visual Studio 2015 and then check to make sure the ChangeLog is updated. Anything else that needs to go into 2.4.10? I don't have anything else I want to add, so I'll probably just test a couple of the new features a bit. |
| 21:25.16 | brlcad | .la files are "libtool archives" only needed by libtool-using applications -- they contain additional metadata that allow a lib to be portably relinked by other libtool applications (referring to macsforme discussion the other day) |
| 21:26.13 | JeffM | he finaly saw the highlight :) |
| 21:26.33 | JeffM | blast007: did you update the runtimes in the installer? |
| 21:26.44 | blast007 | need to do that as well |
| 21:27.15 | brlcad | macsforme: libtool does make it work better cross-platform, not specific to really any platform as long as it's one libtool is ported to, which is still needed today to link correctly on mac, linux, bsd (and windows, but nobody does autotools there) without creating per-platform build rules |
| 21:27.20 | blast007 | I grabbed the latest runtime, and updated my VS2015 to update 3 |
| 21:28.12 | JeffM | just FYI, the VS you have installed should include the runtime installers packed somewhere in it's install dir |
| 21:28.52 | blast007 | k, but I like being able to link to a webpage for them regardless |
| 21:29.02 | JeffM | C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\redist |
| 21:29.03 | JeffM | sure |
| 21:29.05 | brlcad | autotools is pretty much obsolete -- bz should switch to cmake where the build logic can really be made platform agnostic |
| 21:29.14 | brlcad | notes JeffM is right ;) |
| 21:29.30 | blast007 | brlcad: macsforme has been working on premake |
| 21:29.48 | JeffM | it's always good to link, but I just wanted you to know that for an installer, you can always get the runtimes you are building for in as part of the VC install. |
| 21:30.21 | brlcad | blast007: interesting .. they're certainly one of the newest |
| 21:30.25 | brlcad | not used them myself |
| 21:30.40 | JeffM | it is not in many if any of the linux distros |
| 21:30.47 | blast007 | well, older versions are |
| 21:30.53 | brlcad | newest == immature, probably buggy, not available easily, ... ;) |
| 21:30.55 | blast007 | not the alpha that he's targeting |
| 21:31.13 | JeffM | but they would not work for him on OSX right? |
| 21:31.31 | brlcad | xcode is supposedly a target, so it should |
| 21:31.57 | blast007 | JeffM: you mean the older versions of premake? |
| 21:31.59 | JeffM | he said the older versions would not do something he needed |
| 21:32.01 | JeffM | yes |
| 21:32.16 | blast007 | yeah, there was some needed feature in the alpha |
| 21:32.19 | JeffM | that he needed the alpha to get something right on OSX |
| 21:32.29 | blast007 | I don't know if it was specifically for OSX |
| 21:32.38 | tupone | brlcad: Hi :) |
| 21:32.41 | brlcad | the thing is written in C so I can't imagine getting premake itself to compile is at all that complicated |
| 21:32.56 | brlcad | certainly doesn't ship with it preinstalled, so someone has to build it |
| 21:33.06 | brlcad | hi tupone :) |
| 21:33.32 | blast007 | brlcad: well, the alpha version likely won't be in Debian for a number of years |
| 21:33.33 | JeffM | they have premade bins |
| 21:37.26 | brlcad | blast007: the alpha won't likely be on Windows or Mac ever ;) |
| 21:37.47 | JeffM | that's already an issue with dependencies |
| 21:37.48 | blast007 | but *we* package those |
| 21:38.40 | brlcad | so either becomes managed (e.g., shove it in a repo and tell people to get it) and all platforms get packaged that way, or it's off the table no? |
| 21:39.01 | JeffM | that is the current topic of discussion :) |
| 21:39.07 | brlcad | could certainly bundle it like a dep and just compile it as needed |
| 21:39.26 | brlcad | debian folks won't like it but that's a problem for the debian maintainer to sort out ... ;) |
| 21:39.28 | blast007 | fwiw, I first found BZFlag because I was looking through my linux distribution's package manager |
| 21:39.57 | JeffM | how many current people do you think are in a similar situation? |
| 21:40.09 | brlcad | if they can push a new .bz deb, they could probably make a premake .deb update just as easily |
| 21:40.22 | blast007 | JeffM: well, maybe 5 to 10, so ... like half? |
| 21:40.24 | blast007 | ducks |
| 21:40.29 | JeffM | heh |
| 21:40.42 | JeffM | 1/3rd |
| 21:40.45 | brlcad | read that as blast 7 ducks .. so much blood |
| 21:42.55 | JeffM | I agree that it's nice to have the game included in debian, if that is kept as a requirement it's fine, it just needs to be known that it is, and everyone needs to understand what limitations that imposes (versions of SDL, dependencies, etc..) |
| 21:43.20 | JeffM | there are certanly solutions to working around those limitations, they just need to be part of any enhancment. |
| 21:44.16 | JeffM | I'm not personally convinced that debian's update schedule does a good service to the game and it's players, in some ways it encourages people to use old versions. |
| 21:50.20 | brlcad | or just use cmake instead of premake since that's the pervasive build system these days that pretty much replaced autotools and company |
| 21:51.09 | JeffM | he didn't want to learn a new scripting langauge..... |
| 21:55.52 | brlcad | ... I'm not sure that's a solid reason for basing a selection of a build system replacement that should benefit/impact all platforms :) |
| 21:56.11 | JeffM | exactly |
| 21:56.13 | brlcad | cmake is no pretty princess, but it's pretty dead simple to set up |
| 21:57.18 | *** join/#bzflag DTRemenak (~DTRemenak@cpe-172-112-10-183.socal.res.rr.com) |
| 21:57.18 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 21:57.18 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 21:57.19 | brlcad | especially for a build as simple as bz's build |
| 22:10.58 | *** join/#bzflag a_meteorite (~a_meteori@unaffiliated/ameteorite/x-000000001) |
| 22:14.31 | blast007 | as well, some of the dependencies that Windows needs already support premake. (SDL2, curl, zlib) c-ares, pdcurses, and regex does not, but those three are ones we may also replace or no longer use in the nearish future. |
| 22:15.35 | JeffM | .net regex is probably sligtly different from regex lib, just FYI |
| 22:16.03 | JeffM | someone should validate that the regexes that are used work in the standard MS regex (i.e. visual studio) |
| 22:22.05 | blast007 | JeffM: are you referring to this, or something else? https://msdn.microsoft.com/en-us/library/bb982382.aspx |
| 22:22.28 | JeffM | thats one way to get into it, but yes |
| 22:24.56 | JeffM | or you could just swap to std::regex |
| 22:36.05 | JeffM | assuming all the platforms have it in the C++11 implementations |
| 22:37.05 | blast007 | is std::regex the same as std::basic_regex? |
| 22:37.30 | JeffM | not sure, http://en.cppreference.com/w/cpp/regex/regex_match |
| 22:37.44 | JeffM | yes |
| 22:38.10 | JeffM | basic_regex (C++11) regular expression object |
| 22:38.31 | JeffM | http://en.cppreference.com/w/cpp/regex has some samples |
| 22:46.20 | *** join/#bzflag a_meteorite (~a_meteori@unaffiliated/ameteorite/x-000000001) |
| 22:46.32 | JeffM | how much of what you need does boost provide? |
| 22:58.01 | blast007 | has TR1 regex, at least |
| 22:58.15 | blast007 | not sure how/if that differs from the final C++11 standard |
| 23:31.42 | JeffM | is regex used by both the client and the server? |
| 23:38.46 | blast007 | probably, since I believe we use it for the word filter, which is on both |