Meeting 2013 12 02

Servo Meeting 2013-12-02

Agenda

• Anybody want to be my Intel chipset OpenGL testing buddy? (larsberg)
• metabugs vs. milestones (larsberg)
• static linking (jack)

Attending

• larsberg, kmc, jack

OpenGL testing

• larsberg: I'm making lots of changes to support Nvidia cards, but want to make sure I don't break Linux OpenGL on Intel...
• jack: I have an intel chipset
• kmc: I have both intel and nvidia
• larsberg: Great, I'll send mail - I just don't want to break the Intel platform as I work on fixing Nvidia.

metabugs vs. milestone

• jack: We wanted JDM for that. Who has preferences?
• kmc: What are the features they give us?
• jack: Milestones have the progress bar.
• kmc: Can you comment on a milestone?
• jack: Just name, description, and ability to attach bugs to it. And filtering.
• kmc: That means batch-tagging with filtering.
• simonsapin: what for?
• jack: ACID2/ACID3 tracking.
• larsberg: ACID2 has a milestone, ACID3 does not. I was mainly curious about what we should do with ACID2/ACID3 to aid in tracking for Samsung.
• jack: I'll ask Young-Il Wednesday.

static linking

• jack: Should we do this?
• kmc: Sounds good, if it's not a problem getting it working.
• jack: Most is statically linked. libskia and libazure are statically linked into the rust-azure crate. A couple of the sublibraries are dynamic, but could probably be statically liked
• simonsapin: would libstd, libextra be statically linked as well?
• jack: Want this to make demos easier. Right now, having all the libraries, working directories, etc. is a real pain and static linking will heap with nightly snapshots. I'll do this change as part of my build system update.

Build system changes

• simonsapin: Why are there build system changes?
• jack: Three things. 1) have dependencies correctly managed. We miss lots of things right now that make us do 'make clean'. 2) Windows support. 3) Parallelism, since we had to disable it at the toplevel because of rustpkg. Also, the current one has a huge pile of duplicated makefiles everywhere. Changing how things compile require changing all the submodules. Our cross-compiles are also a bit broken.
• simonsapin: Which build system?
• jack: Cmake right now. Tup is the fastest, but it's also not ready for us - running tests, Windows, etc. It's another thing we'd have to get / compile and the syntax is a bit weird. The Lua syntax and regular syntax. Cmake can generate both Makefiles and ninja files. It'll work for most people using make, but we can all use ninja since it's way faster for incremental builds. Handles all the dependency stuff fine (relies on my rust packages). The only difference is that the way tup works is it uses either dynamic linking hacks or userspace filesystem to track what files the rust compiler opens in order to build something. So the template generator wouldn't have to declare the dependencies - the tool just detects what it reads.
• jack: In cmake, if you change the lib.rs file, you may have change the package id, so then we have to rebuild the cmake files. So there's a fake rule there to make the dependency work. In tup, it knows that when it built, there was a dependency and finds it all. Tup can also find things that you've missed and generate errors. Leaning towards cmake, but the tup author is a Mozilla employee. Opinions?
• simonsapin: Not really.
• jack: Like to support tup. But we have so much exploratory code already...
• larsberg: Minimizes moving parts. We have reasons to believe it will "just work" for us.
• jack: And cmake has autoconf built in. And all the different builds - debug/release/cross-compile. For tup, we'd need to cross-compile.
• kmc: Hopefully not configure scripts and cmake and ninja.
• jack: Right, just cmake files do everything and you can generate either makefiles or ninja scripts. Once my Rust fixes go in for the build system, I'll do the upgrade to Rust and land our build system changes.
• kmc: for rustpkg?
• jack: I added support for rustc to generate the equivalent of -MMD all the makefile rules for the dependencies, which we want. Also, currently crate hashes are pseudo-random numbers. I have a patch that makes them stable so that cmake can compute them before running the rust compiler. Those two give us a reliable build system without linking against librustc. Also need other stuff: PAtrick's stuff needs new compiler features. We backported in the chase-lev deque. We lose do and proc change.
• larsberg: and linked task failure
• kmc: Losing do because it's sugar for procs?
• jack: They were getting rid of closure type inference. Could infer an owned closure and allocate. Now have &fn (stack closures) and ~fn (proc, also a once fn). do only works with procs. The whole point was for do spawn sugar. Problem is that we used do for the &fn versions. It's not a big deal, but the big one is that ~fn is now once so we no longer need Cells. Stuff where we were taking advantage of non-onceness will require some significant changes.
• kmc: I can help with the rust upgrade, if you want.
• jack: Easiest to start with is replacing linked task failure with task::try.