00:41:12  * indexzerojoined
00:47:19  * indexzeroquit (Quit: indexzero)
01:03:19  * xmingquit (Ping timeout: 245 seconds)
03:00:40  * xmingjoined
07:19:47  * mmaleckijoined
08:10:32  * mmaleckiquit (Ping timeout: 276 seconds)
08:28:36  * xmingquit (Changing host)
08:28:36  * xmingjoined
08:34:52  * mmaleckijoined
09:32:19  * mmaleckiquit (Ping timeout: 245 seconds)
09:49:53  * mmaleckijoined
10:20:57  * tim_smartchanged nick to tim_smart|away
10:36:08  * mmaleckiquit (Quit: Lost terminal)
10:36:30  * mmaleckijoined
12:18:26  * neomantrajoined
12:57:18  * mmaleckiquit (Ping timeout: 250 seconds)
13:04:23  * TheJHjoined
13:28:24  * mmaleckijoined
13:52:31  * dvvjoined
14:07:31  * pancakejoined
14:07:32  <pancake>oi
14:14:43  * neomantraquit (Quit: Leaving.)
14:15:25  <xming>o/
14:18:29  <pancake>what about using polarssl instead of openssl in luvit?
14:18:36  <pancake>the package would be far more smaller
14:31:06  <dvv>license?
14:31:07  <dvv>hi
14:33:08  <pancake>http://polarssl.org/
14:33:26  <pancake>http://polarssl.org/licensing
14:33:32  <xming>GPL :D
14:33:51  <pancake>i think gpl can be problematic here..
14:34:03  <dvv>?
14:34:04  <xming>which will make all luvit mandaratory GPL
14:34:10  <pancake>yep
14:34:14  <pancake>and if you embed luvit in any app
14:34:19  <pancake>that one must be gpl
14:34:23  <dvv>i believe only if we do static linking, no?
14:34:42  <pancake>thats what ppl will do in iOS for example
14:34:52  <pancake>GPL was not designed for libraries
14:35:18  <dvv>i'm currently fighting with building luvit for my android tablet
14:35:19  <pancake>and paying 2750e for a commercial license is not an option
14:35:35  <pancake>im fighting to build luvit on my company's sdk
14:35:44  <rphillips>yeah, gpl is a non-starter I believe
14:35:45  <pancake>it was building fine on 0.3.1
14:35:47  <pancake>but not for 0.4
14:36:01  <dvv>i open an issue on uv_stdio
14:36:43  <dvv>seems libuv have advanced and we can't use its latest master
14:42:15  * kevwiljoined
15:00:55  <dvv>not funny thing is that we need host luvit to build bundled luvit. this breaks cross-compilation
15:04:03  * kevwilquit (Quit: WeeChat 0.3.8)
15:04:50  * kevwiljoined
15:11:52  <xming>dvv, see my cmake build, no need for luvit to bundle
15:12:06  <pancake>build fixed
15:12:41  <dvv>xming: where to look?
15:13:05  <xming>https://github.com/luvit/luvit/issues/251
15:13:27  <xming>for now you need all system libs for libuv, http_parser, openssl and yajl
15:13:41  <pancake>anyone started supporting objc-ffi?
15:13:59  <xming>I am asking for comments before I make advances
15:15:18  <rphillips>pancake: trying to get an alias to work in luvit-options.
15:15:19  <xming>oh and you need system luajit too
15:15:27  <rphillips>/modules/options/modules/init.lua:83: attempt to concatenate local 'b' (a table value)
15:15:41  <pancake>rphillips: uhm
15:15:57  * mmaleckiquit (Ping timeout: 250 seconds)
15:16:08  <rphillips>actually, it's line 82
15:16:08  <xming>dvv: even the current bytecode generation will break cross-compilation
15:16:18  <dvv>^^^
15:16:44  <xming>rphillips: why doesn't luvit have -g and -b options?
15:16:53  <pancake>rphillips: how can i reproduce it?
15:16:58  <rphillips>checking
15:17:03  <rphillips>perhaps I'm not using the latest version also
15:19:00  <xming>pancake: linking dynamically to openssl makes it small too :D
15:19:17  <xming>-rwxr-xr-x 1 xming xming 735284 Jun 18 15:35 luvit
15:19:27  <xming>this is a bundled build :D
15:19:31  <pancake>xming: yeah :P
15:19:31  <rphillips>stripped?
15:19:37  <xming>not stripped
15:19:45  <xming>-rwxr-xr-x 1 xming xming 670168 Jun 18 17:18 luvit
15:19:49  <xming>now stripped :D
15:19:58  <rphillips>nice
15:20:19  <xming>and it uses 33% less momory
15:20:27  <xming>2MB instead of 3MB
15:20:32  <creationix>this is why I want to make luvit more modular
15:20:44  <creationix>most the time I don't need openssl or zlib
15:20:47  <xming>creationix: I have already started working towards that goal
15:20:54  <creationix>xming, :)
15:21:39  <pancake>creationix: did you checked that objc-ffi thing?
15:21:41  <xming>and for my needs (no ssl, no http_parse, no json, no zlib) the executable is even smaller, and memory is down to 1.4MB
15:21:45  <creationix>pancake, not yet
15:21:56  <creationix>xming, btw, does cmake help with cross-compiling?
15:22:06  <xming>creationix: if you have time can you check https://github.com/luvit/luvit/issues/251
15:22:13  <creationix>what about the step where we use host luajit to compile the lua scripts into bytecode
15:22:22  <xming>creationix: I do that
15:22:37  <xming>tools/bindle.lua is totally eliminated
15:22:44  <creationix>nice
15:22:50  <pancake>i'm with opening a bug to rewrite the build system with foobar after the cmake build system gets done ;D
15:23:23  <creationix>I hate all build systems, they get in the way too much
15:23:28  <creationix>I just want to write code
15:23:38  <creationix>(this may be why I prefer scripting languages, no build step)
15:23:41  <xming>I also want that anyone can write models and drop them to src/modules/MyMod
15:23:54  <xming>and just rerun cmake . && make
15:24:00  <creationix>xming, yep
15:24:02  <xming>and it get compiled and bundled
15:24:14  <creationix>I have several desktop and mobile apps I want to make using luvit
15:24:19  <xming>s/models/modules
15:24:30  <creationix>and even the rackspace guys don't build vanilla luvit, they embed it in their app
15:24:38  <dvv>we can ship "bootstrap luvits" for various OSes and make build system depend on only them (plus vanilla build essentials), no?
15:24:47  <xming>I can generate .a and .so easily with cmake
15:24:50  <pancake>i started writing my own build system named 'cake'
15:24:58  <dvv>hehe
15:25:06  <pancake>which is written in C and "makefiles" are just include files
15:25:16  <xming>dvv: cmake should be crossplatform enough
15:25:26  <pancake>Cakefiles are included from cake.c which describe the deps between modules in arrays of structs
15:25:33  <dvv>does it build agains uClibc?
15:25:47  <xming>should be possible
15:25:58  <xming>if you meet the requirements
15:26:12  <xming>and the luvit code is uclibc compatible
15:26:23  <xming>dvv: try it and tell me please :D
15:26:29  <dvv>to clarify, i mean "cmake is linked against uClibc"
15:26:33  <dvv>hehe
15:27:21  <xming>from what I have read cmake runs fine on uclibc env
15:27:41  <dvv>the times i drove my linux distro it didn't
15:27:49  <dvv>KNOWN BUGS at https://bitbucket.org/dvv/brave-mouse
15:29:13  <dvv>but afaicr cmake is just a layer atop of vanilla make et al., no?
15:29:26  <xming>dvv: I haven't tried it, but google tells me that there are cmake in some ditro's toolchain, e.g. http://permalink.gmane.org/gmane.comp.embedded.embtoolkit.scm/80
15:29:32  <dvv>it's better to employ luarocks then, imho (hehe)
15:30:24  <xming>well cmake is more cross-platform than Makefiles + shell hacks
15:31:09  <dvv>i still dream of luvit being just a library for luajit
15:32:52  <dvv>xming: right. but libraries we use are rather consistent in building, no? the hackish openssl however occupies a half of luvit's makefile. what's the purpose, instead of making optional ssl.luvit?
15:33:12  <xming>creationix: RE cmake and cross-compiling, not really, you still needs to be careful of what you do, but IMHO camke can help to do that more easy
15:35:14  <xming>dvv: isn't providing the choice during compile/configure time a good idea?
15:36:15  <dvv>a good one
15:36:33  <xming>creationix: the current cmake luvit should be cross-compiling safe
15:37:06  <xming>dvv: this is the cmake luvit gives us, run "ccmake ." and you can choose what you want
15:37:36  <xming>system libs or not (not implemented), ssl or not, http or, not, ... bundled or not
15:38:14  <xming>and cmake luvit support out of tree building :D
15:38:34  <xming>one source tree and different output dirs :D
15:58:14  <dvv>cool
16:06:58  * mkandrashoffjoined
16:08:04  * dvvquit (Ping timeout: 248 seconds)
16:11:39  <rphillips>pancake: https://github.com/radare/luvit-options/pull/4
16:11:50  <pancake>letme see
16:14:33  <pancake>looks ok to me as long as it works for you
16:14:36  <pancake>i have no test case to test it :)
16:14:45  <pancake>so i can accept that pullreq if you want
16:16:59  <rphillips>i'm testing it out now and haven't had an issue
16:17:55  <pancake>accepted
16:17:57  <pancake>thanks
16:20:52  * dvvjoined
16:42:41  * pancakequit (Quit: ZZZ)
17:21:07  * mmaleckijoined
18:18:57  * mmaleckiquit (Ping timeout: 246 seconds)
18:21:54  * mmaleckijoined
18:26:00  <xming>dvv: node for lua https://github.com/ignacio/LuaNode
18:28:19  * Kami_quit (Excess Flood)
18:31:58  * mmalecki_joined
18:32:22  * Kami_joined
18:34:47  * mmaleckiquit (Ping timeout: 256 seconds)
18:35:05  * mmalecki_changed nick to mmalecki
18:42:12  <creationix>wow, codea looks a lot nicer than it used to
18:42:25  <creationix>still think developing *on* a tablet is painful
18:48:12  <xming>creationix: do you have any comments on my RFC?
18:49:16  <xming>at least do you think we should go in that direction?
18:54:16  <creationix>xming, I know I want to go in the direction of making luvit modular where people can drop in modules and then build
18:54:26  <creationix>as far as which build system, whatever is the least work
18:55:45  <xming>okay so we agree that's the direction we want, as for which build system, I am more familiar with cmake
18:56:03  <xming>creationix: do you know what the plans are with ninja?
18:56:37  <xming>it looks like philips and I are working in parallel with 2 different build systems
18:59:15  <levi>Build systems are evil.
19:04:39  <rphillips>we have makefiles, gyp, and now cmake
19:05:03  <rphillips>i hate build systems
19:05:56  <rphillips>ninja will use the gyp generated makefiles and probably others
19:06:50  <xming>cmake should eliminate makefiles bundle.lua and gyp
19:07:47  <rphillips>bundle.lua isn't used in the gyp build
19:07:53  <rphillips>afaik
19:09:44  <creationix>right, bundle.lua is only used by Makefile
19:11:00  <xming>so the goal is to use ninja to use the gyp to generate Makefiles on *nix?
19:11:41  <xming>needing python to build is just an overkill IMHO
19:15:08  <rphillips>i honestly don't want to manage a build fork of libuv
19:16:55  <xming>rphillips: huh? What do you mean?
19:17:03  <creationix>is libuv that hard to build on windows?
19:17:13  <creationix>it build pretty easily on *nix using the plain Makefile
19:17:46  <xming>I have look at it it's not that hard, I can cook up cmakefiles for you to test if yo want
19:18:23  <rphillips>probably not all that hard no
19:18:28  <xming>rphillips: what do you use on windows for compiling? VS or cygwin/ming alikes?
19:18:39  <rphillips>VS, but others want mingw support
19:18:56  <xming>others?
19:19:20  <rphillips>pancake who isn't in the channel, ATM
19:19:29  <xming>properly coded cmakes can generate vs proj and hsould work fine too under mingw
19:20:43  <xming>and mingw can have system installed libs and have luvit just link dynamically to them
19:21:03  <xming>VS is an area where I am unfamiliar with
19:23:12  <xming>creationix: btw cmake can generate xcode proj file for you to build luvit on your new shiny iPad :p
19:24:21  <rphillips>to be fair, gyp does that also
19:25:12  <creationix>right, so cmake is a gyp replacement
19:25:18  <creationix>and ninja is a make replacement
19:25:21  <creationix>more or less?
19:25:22  <xming>well it doesn't have to be cmake
19:25:43  <xming>I just hate the multiple/differnt paths of the build right now
19:25:48  <creationix>agreed
19:26:01  <xming>I would like to see a uniformed *one* build system
19:26:20  <xming>preferably for _all_ platforms
19:26:29  <rphillips>i can agree with that
19:26:31  <xming>or at least enough platforms
19:26:46  <xming>and I am more familiar with cmake
19:26:53  <creationix>windows + ubuntu + archlinux + osx + iOS + android + raspberry pi
19:26:53  <xming>and this is the way I can contribute
19:26:56  <creationix>those are my targets
19:27:32  <xming>hence I put out RFC and I am waiting feedback before I continue even more
19:27:47  <rphillips>RFC to the mailing list?
19:28:00  <creationix>yep
19:28:25  <xming>if someone thinks gym/ninja/XYZ is better and can lead the taks, I am also willing to help, but I probly can't help much
19:28:32  * kevwilquit (Quit: WeeChat 0.3.8)
19:28:46  <xming>rphillips: https://github.com/luvit/luvit/issues/251
19:29:13  <creationix>ahh, github mailed me, hence why I thought it was to the ml
19:29:23  <xming>the tarball there is just a show case of what's done and what's possible (on *nix)
19:29:28  <xming>we have a ML?
19:30:01  <xming>ah never took attention to http://luvit.io/ :D
19:30:06  <creationix>interesting http://code.google.com/p/gyp/wiki/GypVsCMake
19:31:03  <xming>since we all agree on the direction of how things should be done, this makes everything a lot easier already
19:31:35  <creationix>so libuv's primary use is in node and node depends on v8
19:31:43  <xming>it's just time to take technical decisions
19:31:47  <creationix>nobody wants to maintain a v8 make system outside what google does
19:32:01  <creationix>which makes things weird for us because we don't even use v8
19:32:24  <creationix>(and actually, v8 only uses it because chromium does)
19:33:01  <creationix>xming, I don't care what system we use. My preference is simple
19:33:06  <creationix>I know Makefile
19:33:22  <creationix>but I understand that Makefile doesn't work so well on windows
19:33:26  <creationix>and cross-compiling can be a pain
19:37:30  <creationix>xming, rphillips do we need a build generating system at all?
19:37:56  <creationix>how hard would it be to maintain hand-written a Makefile
19:37:56  <xming>creationix: yes, because to platform differences
19:38:14  <xming>or eles we would be maintaining Makefiles vs proj, xcdeo proj, ....
19:38:25  <xming>maintaining Makefiles is easy :D
19:38:28  <rphillips>it's nice getting visual studio, and xcode project files generated
19:38:31  <creationix>osx desktop works fine with Make
19:38:37  <creationix>but I guess iOS is another story
19:38:40  <xming>yes, but not VS
19:38:48  <xming>mingw works with Makefiles too
19:38:58  <creationix>right, but mingw is not the same
19:39:21  <xming>creationix: do we want to build the deps (openssl, yajl, uv,...) ourselves?
19:39:58  <creationix>I like bundling them
19:40:21  <xming>and I don't, so this should still be a configure/compile time feature
19:40:32  <creationix>I wonder if the openssl "module" should static link at bundle time or build as a .so/.dll and dlopen at runtime
19:41:05  <creationix>by "bundling" I mean the build system manages them
19:41:11  <creationix>not that it's there in the default build
19:41:14  <xming>I know, and I don't like that
19:41:39  <creationix>xming, are you saying openssl should have it's own build system apart from luvit then?
19:41:40  <xming>I don't like packages bundling external dependencies
19:41:52  <xming>no that is not what I meant
19:42:08  <creationix>though openssl is a bad example, I'm generally fine with dlopening the system openssl
19:42:10  <xming>I mean I disklike that, but there are certainly people who like that
19:42:22  <xming>so this should be a user choice too
19:42:41  <xming>certainly for windows, it's nice to do that
19:43:01  <creationix>true
19:43:02  <xming>or "less" featured system
19:43:30  <creationix>so, in the end, I want to be able to build a single "luvit" binary
19:43:42  <creationix>I don't really care if it uses static openssl or links in the system version
19:43:52  <creationix>but, I do care about how easy it is to customize that
19:44:24  <creationix>I also really want the ability to build custom apps (customized luvits) as single binaries
19:44:39  <xming>creationix: look at that tarball I uploaded, you can see you can choose that, just the bundled dependencies do no work ATM (WIP)
19:44:52  <xming>creationix: yeah I want that too
19:45:09  <creationix>how bare should the core be?
19:45:21  <xming>and I want be able to cross-compile and bundle as one BIN
19:45:42  <creationix>what *is* luvit if zlib, openssl, yajl, and even libuv are external modules?
19:45:51  <creationix>at that point, it's just luajit
19:45:57  <xming>right now? it can be build and running my app w/o http_parser, yajl, ssl, zlib
19:46:15  <xming>it has libuv, that's core IMO
19:46:23  <creationix>ok, so luvit is luajit + libuv
19:46:29  <xming>IMHO yes
19:46:34  <creationix>with this awesome feature to customize as an app
19:47:09  <creationix>and it doesn't have to be luajit, stock lua will work too?
19:47:21  <creationix>or do we want to make a hard dependency on luajit?
19:47:47  <xming>right now I also bundle all .lua, but that should be changed too depending the feature (as if I don't link against openssl then no need to bundle tls.lua ...)
19:47:58  <creationix>xming, right
19:48:12  <creationix>the addons should be able to contain C bindings, static libs, dynamic libs, and lua scripts
19:48:20  <xming>I think that we should allow to link to lua, there is even a bug for that
19:48:20  <creationix>and/or ffi bindings
19:48:38  <xming>indeed
19:48:42  <xming>that's my idea
19:48:47  <creationix>great
19:48:52  <xming>in a well structure directories
19:49:06  <xming>and the build system should look for them
19:49:12  <creationix>I also want it to be able to run in two modes, bundled and developer
19:49:19  <creationix>so while developing, I can run as a directory
19:49:24  <creationix>but then bundle to a single binary when done
19:49:41  <creationix>I can even deploy as a directory in a tarball if I want to make my app super hackable
19:49:54  <creationix>I do a lot of programming education, that's a nice feature
19:50:02  <xming>a build system can generate different outputs, like Debug, Release, ....
19:50:39  <xming>my camke can do out-of-tree compiling, which means you can have both with a single source tree
19:50:50  <creationix>well, I mean more of a no-build step where the core (luajit + libuv + luvit base) is built, but everything else is loaded at runtime without a build step
19:51:11  <creationix>what is "out-of-tree" compiling?
19:51:23  <xming>not compiling in tree
19:51:27  <xming>like this
19:51:41  <xming>you have /home/xming/src/luvit
19:51:52  <xming>you do mkdir /home/xming/src/luvit.out
19:52:10  <xming>cd /home/xming/src/luvit.out && cmake ../luvit && make
19:52:24  <creationix>I see
19:52:25  <xming>no single file generated will polute /home/xming/src/luvit
19:52:41  <xming>so you can have /home/xming/src/luvit.Debug
19:52:45  <xming>so you can have /home/xming/src/luvit.Release
19:52:46  <xming>...
19:53:14  <xming>I also hate build system polluting src dir :D
19:53:29  <creationix>so my case (assuming vanilla Make because that's all I know). I `make core`, then create lua scripts in modules/*, running and testing the app without a build step, and then `make bundle` to generate the final single-binary
19:53:32  <xming>especially system that generates .c and .h :D
19:54:09  <creationix>how could the out-of-tree "core" build read the lua scripts in the src directory
19:54:44  <xming>either we patch luavit to look for the modules
19:54:51  <xming>or you need to do 'make install'
19:55:06  <xming>or
19:55:32  <creationix>ok, so build core to an out-of-tree place, and then run the local version using the remote core
19:55:40  <xming>we can do a fake install, like 'make InstallHereUnderSourceDir'
19:56:48  <xming>or really hackish to do bunch of sym links :D But that won't work under windows :(
19:57:03  <creationix>yeah, I'd like to avoid symlinks
19:57:12  <xming>For that I still need to think through, but ATM I think it's solvable
19:57:20  <creationix>currently the "developer" mode works by searching for scripts relative to the luvit binary
19:57:32  <xming>I noticed that
19:57:35  <creationix>we could maybe change that to be cwd instead
19:57:44  <creationix>but then it's harder to start the app
19:57:46  <xming>creationix: ah one thing, why doens't luvit have -g -b ?
19:58:08  <creationix>because I'm a scripting language guy
19:58:16  <creationix>I'm not against them
19:58:19  <creationix>just overlooked
19:58:49  <xming>if someone has luvit statically linked against luajit, then he can't generate bytcode
19:58:53  <creationix>for the case where I ship my app as a tarball, loading module relative to the binary is super useful
19:59:04  <xming>unless he searches in the building dir
19:59:18  <creationix>oh, those flags
19:59:24  <creationix>I'm fine with adding them
19:59:25  <creationix>just not sure how
19:59:36  <creationix>I guess there is a C api to them through luajit?
19:59:39  <xming>what had you in mind?
19:59:57  <xming>yeah, like in lua
20:00:04  <xming>but for a more simple lua scripter
20:00:08  <xming>well
20:00:44  <xming>I still hope that we can have a consensus of what we are going to use
20:01:07  <xming>I don't like people doing things in parallel and I dont like step on others' toes
20:01:35  <creationix>so i stink at build systems. I've been developing in scripting languages for the last 20+ years
20:01:45  <xming>I still like to have a "GO" from most devs here before I continue
20:02:02  <creationix>xming, I like the idea, just want to make sure we all agree
20:02:42  <xming>creationix: I have been doing all kinds of things in the last 20 years :D HAcking/Deving in all sort of things, build systems, system/network managements
20:03:03  <xming>creationix: I think that everyone agrees more or less on the idea
20:03:09  <creationix>philips, rphillips and pquerna work more on luvit than I do these days, so their opinion counts
20:03:20  <xming>but not on the technical points
20:03:42  <creationix>right, so I don't think that maintaining a cmake system for libuv is that much work
20:03:56  <creationix>especially if you xming would be willing to maintain it
20:04:01  <creationix>I doubt the libuv guys will
20:04:20  <creationix>and luajit is just Makefile right?
20:04:27  <creationix>we added the gyp layer I think
20:04:35  <creationix>http_parser is so simple it doesn't matter really
20:04:48  <xming>I look dive into that first, it seems that rphillips has objection to fork uv's build system
20:04:53  <creationix>openssl is a beast, but I'm sure there are cmake scripts for it
20:05:05  <creationix>he just doesn't want to maintain a fork
20:05:05  <xming>I thnik that libuv can be build w/o v8 dependency
20:05:26  <rphillips>it already is built without v8 deps
20:05:31  <creationix>I'm no expert on windows though
20:05:42  <creationix>I don't know how hard libuv is to build
20:05:56  <xming>creationix: for openssl, do we want to bundle it? Most systems have openssl even windows
20:06:11  <rphillips>pquerna and philips are OOO today.
20:06:11  <creationix>rphillips, do you remember why node decided to bundle openssl
20:06:21  <creationix>it didn't used to
20:06:51  <creationix>I think it was to ensure node had a certain version with a specefic feature
20:07:03  <rphillips>not specifically, but our reason is that we wanted to control the openssl version
20:07:04  <xming>rphillips: if you, pquerna and philips can give me a "Go an try", then I am fine
20:07:17  <creationix>rphillips, right, for your app it makes sense
20:07:34  <creationix>rphillips, you don't control the systems you run on
20:07:37  <xming>rphillips: if you guys are working one a system for all platform, then I am fine with taht too
20:08:14  <creationix>ok, so https is an interesting module
20:08:21  <xming>rphillips: how does openssl build on windows? Does it have VS proj files?
20:08:32  <creationix>if we make openssl and http_parser external, which module includes https.lua?
20:08:42  <creationix>since it depends on both http_parser and tls.lua
20:08:59  <xming>hehe, nice one :D
20:09:05  <xming>IMHO http
20:09:11  <xming>tls is transport
20:09:24  <creationix>maybe just a conditional tls require and feature detect?
20:09:33  <xming>yeah
20:09:38  <creationix>that sounds sane enough
20:09:44  <rphillips>xming: the makefiles and gyp scripts build openssl
20:09:57  <rphillips>it will also generate project files for windows
20:10:16  <rphillips>+1 on the feature detect
20:10:39  <xming>rphillips: is it gyp that generates vs proj?
20:10:54  <xming>rphillips: vanilla openssl doens't have gyp, does it?
20:11:01  <rphillips>gyp will generate makefiles, xcode projects, and vs projects
20:11:10  <rphillips>it does not... but it's a list of files we compile
20:11:55  <xming>so basically you use gyp internally for building "non native" libs/apps?
20:13:45  <rphillips>non native?
20:16:51  <xming>projects w/o native VS proj. generating capabilities
20:17:26  <rphillips>we are using gyp because we needed a build system that works on linux, osx, and windows
20:18:10  <rphillips>we felt that gyp had a more sane description language
20:21:19  <xming>hehe, in the link that creationix pointed out, it says otherwise :D
20:21:37  <xming>"CMake includes a fairly readable imperative language. Currently Gyp has a somewhat poorly specified declarative language (variable expansion happens in sometimes weird and counter-intuitive ways).
20:23:58  <rphillips>it's fair and honest :)
20:24:26  * tim_smart|awaychanged nick to tim_smart
20:30:34  <creationix>To be honest, I don't care if we use cmake or gyp, cmake seems like a better fit got luvit, but libuv already has gyp and we already added gyp to openssl, zlib, and http_parser
20:33:17  <rphillips>+1. if I see a pull request with cmake support and it supports the same features and more, then I don't see a reason to not try it out
20:33:43  * mmaleckiquit (Ping timeout: 252 seconds)
20:34:03  <creationix>since I can compile *on* the raspberrry pi using archlinux, getting python isn't a pain
20:34:21  <creationix>just annoying
20:34:32  <creationix>"why do I need python to build lua!?!"
20:35:27  <creationix>xming, ok, if you're willing to write cmake scripts for the current bundled dependencies than I think we can accept it
20:35:55  <creationix>yajl was cmake upstream if I remember correctly
20:36:08  <creationix>and I'm sure someone has done it already for openssl and zlib
20:36:11  <creationix>they are super popular
20:39:34  <creationix>xming, I think you share my vision about how to structure the build process
20:45:44  <creationix>can cmake use ninja instead of make?
20:45:57  <creationix>that should make building openssl a bit faster
21:10:24  * mkandrashoffpart
21:13:59  * dvvquit (Ping timeout: 245 seconds)
21:16:41  * tokyodanjoined
21:26:23  * tokyodanquit (Quit: tokyodan)
21:27:52  * dvvjoined
21:41:24  * TheJHquit (Ping timeout: 240 seconds)
21:41:45  * pancakejoined
21:55:15  <xming>I don't know about ninja
21:56:48  <pancake>ninja?
21:57:21  <xming>http://martine.github.com/ninja/
21:57:29  <xming>YABS
21:57:43  <xming>Yet Another Build System :/
21:59:44  <xming>creationix: it seems that cmake has ninja generator
22:01:56  <pancake>oh
22:02:06  <pancake>no more build systems
22:02:11  <pancake>we should write our own :D
22:10:45  <xming>rphillips: can you apply this https://github.com/luvit/luvit/issues/250 ?
22:13:29  <rphillips>xming: it's best as a pull request
22:13:41  <rphillips>also the gyp and makefiles need to be upgraded to default those to be on
22:17:16  <xming>oh ah right
22:17:24  <xming>forgot about that
22:18:48  <xming>I'll sent pull request when I get things more in shape
22:19:38  <rphillips>k
22:52:29  * mkandrashoffjoined
22:52:54  * guybrushquit (*.net *.split)
22:53:22  * guybrushjoined