Example generated bindings: https://gist.github.com/Diggsey/c8a4cb93c7d5643d20203401ead178a7

This can't be merged until:

1. I've tested it beyond the bindings compiling
2. The next version of stdweb is released, which will contain the CanvasElement type

Minimal reproducible case here: https://github.com/zacps/gl-error OpenGL Extensions Viewer produces the following information: https://drive.google.com/open?id=1wGiFhQkl2_af0MPlr4FanPmhyWUXbjqR

OS: Windows 10 build 1703 GPU: GTX 970 Nvidia driver version: 388.13 Rust toolchain: {stable, nightly}-x86_64-pc-windows-msvc Build: release & debug

This change will totally remove the generate_gl_bindings macro, in favor of Cargo build scripts.

If you simply use the gl library, nothing changes.

If, however, you use gl_generator, then instead of:

generate_gl_bindings! {
 api: "gl",
 profile: "core",
 version: "4.5",
 generator: "global",
 extensions: [
 "GL_EXT_texture_filter_anisotropic",
 ],
}

Replace this by:

include!(concat!(env!("OUT_DIR"), "/gl_bindings.rs"));

And create a file named build.rs:

extern crate gl_generator;
extern crate khronos_api;

use std::os;
use std::io::File;

fn main() {
    let dest = Path::new(os::getenv("OUT_DIR").unwrap());

    let mut file = File::create(&dest.join("gl_bindings.rs")).unwrap();

    gl_generator::generate_bindings(gl_generator::GlobalGenerator,
                                                   gl_generator::registry::Ns::Gl,
                                                   khronos_api::GL_XML,
                                                   vec!["GL_EXT_texture_filter_anisotropic".to_string()],
                                                   "4.5", "core",
                                                   &mut file).unwrap();
}

You will also need to tweak your Cargo.toml:

[package]
# ...
build = "build.rs"

[build-dependencies.gl_generator]
git = "https://github.com/bjz/gl-rs"

[dependencies.gl_common]
git = "https://github.com/bjz/gl-rs"

# remove [dependencies.gl_generator]

This should bring gl-rs up to date. The main change is due to rust now namespacing enums. Additionally, ast::TyPath now only takes two arguments.

Please note that this technically does not build against the current master branch of rust due to an ill-defined quote_ty macro. However, once https://github.com/rust-lang/rust/pull/19387 is fully merged things should again work as expected.

Credit goes to @arielb1, who found this while investigating rust-lang/rust#34166.

This patch also improves compile times of glium using old trans:

Before patch:

time: 0.654; rss: 420MB Prepare MIR codegen passes
  time: 1.500; rss: 456MB   write metadata
  time: 0.272; rss: 458MB   translation item collection
  time: 0.047; rss: 459MB   codegen unit partitioning
time: 4.595; rss: 568MB translation
time: 0.004; rss: 568MB assert dep graph
time: 0.000; rss: 568MB serialize dep graph
  time: 1.280; rss: 294MB   llvm function passes [0]
  time: 24.618; rss: 324MB  llvm module passes [0]
  time: 10.087; rss: 322MB  codegen passes [0]
  time: 0.004; rss: 190MB   codegen passes [0]
time: 36.471; rss: 172MB    LLVM passes
time: 0.299; rss: 174MB linking

After this patch:

time: 0.587; rss: 414MB Prepare MIR codegen passes
  time: 1.396; rss: 459MB   write metadata
  time: 0.265; rss: 460MB   translation item collection
  time: 0.050; rss: 461MB   codegen unit partitioning
time: 4.449; rss: 570MB translation
time: 0.003; rss: 570MB assert dep graph
time: 0.000; rss: 570MB serialize dep graph
  time: 1.271; rss: 292MB   llvm function passes [0]
  time: 20.428; rss: 314MB  llvm module passes [0]
  time: 8.931; rss: 313MB   codegen passes [0]
  time: 0.004; rss: 177MB   codegen passes [0]
time: 31.011; rss: 168MB    LLVM passes
time: 0.257; rss: 169MB linking

On my i5-3550 this code takes 3.2 seconds to build, which is quite a bit taking into account it is only loading the OpenGL library.

extern crate glutin;
extern crate gl;

fn main() {
    let window = glutin::Window::new().unwrap();
    unsafe { window.make_current() };
    gl::load_with(|symbol| window.get_proc_address(symbol));
}

It was tested with rustc 1.0.0-nightly (dfc5c0f1e 2015-02-18).

These aliases are already present in the XML, so we might as well use them! As OpenGL evolves and is extended, it frequently occurs that a vendor introduces an extension, giving a function a name like glFooNV or glFooAMD. Then, it gets proposed to the ARB and is renamed glFooEXT. Then, this extension gets standardized and is placed in the core profile and is once again renamed to its final name, glFoo.

For Mesa, they implement various extensions and then finally support an OpenGL version once all extensions have been implemented. Many OpenGL features can be implemented entirely in the driver, or on most hardware even if the hardware doesn't support enough features for a specific OpenGL version. So you get situations where older GPUs only expose OpenGL 2.1, but implement almost every extension that is present in OpenGL 3.3.

So, when glFoo can't be loaded but it has known aliases, try also loading those aliases before giving up.

Closes #150

It is defined as a valid enum here: https://www.opengl.org/sdk/docs/man3/xhtml/glGetActiveUniformBlock.xml

Is it a bug in the GL spec that you parse?

My glxinfo: https://gist.github.com/kvark/fe9f69f1dc84d3ff9621 Reports that OpenGL Core 3.3 is supported, and I see GL_ARB_uniform_buffer_object in the extension list.

The definition of PROC causes issues on the latest nightly. The functions aren't allow to be zero, which rust makes use by annotating them with non-null. Unfortunately, the returned functions by wglGetProcAddress can be zero (e.g GL1.1 functions). Glutin currently checks if the functions are zero else it queries the addresses via kernel32::GetProcAddress. The rust compiler optimizes this call away as it assumes we don't have null functions.

The proposed solution is to replace extern "system" fn() with *const (), which also fixes the issue for me locally.

I'm developing an app with emscripten + WebGL, and using gl-rs to generate the GL bindings. While WebGL and GLES are similar enough that GLES works, using GLES results in hundreds of (non-fatal) errors like "bad name in getProcAddress: glActiveShaderProgram,glActiveShaderProgram", and if you accidentally call a function that isn't supported by WebGL, it seems to jump to an arbitrary address. Adding WebGL support would prevent this kind of thing, and might also allow WebGL extensions.

Scenario:

Thread 1              |  Thread 2
========              |  ========
driver1::make_current |
gl::load_with         |
                      |  driver2::make_current
                      |  gl::Begin() // crash!

In general, loading GL functions can be thread-specific, and only the struct loader can deal with this. Every function in the static loader should be marked unsafe, and it should be heavily discouraged.

I noted that https://github.com/brendanzab/gl-rs/pull/530. It has been inactive for a year. I have the same issue with no_std support.

All the "OS dependent" things that gleam uses are type definitions, it's not necessary to depend on the std crate.

unsafe {
  let mut vao = 0;
  gl::GenVertexArrays(1, &mut vao);
  assert!(vao != 0);
}

this code panics. But if i change the initial value of vao to anything else(for example 1), it doesn't panic. Similar thing with other functions that get pointers as arguments, they don't seem to modify anything so i can't create any objects or get error logs.

On https://github.com/rust-windowing/glutin/issues/1307 we get errors:

error[E0599]: no method named `set_suspend_callback` found for reference `&EventLoopWindowTarget<T>` in the current scope
  --> /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/glutin-0.27.0/src/api/android/mod.rs:76:12
   |
76 |         el.set_suspend_callback(Some(Box::new(move |suspended| {
   |            ^^^^^^^^^^^^^^^^^^^^ method not found in `&EventLoopWindowTarget<T>`

error[E0615]: attempted to take value of method `SwapBuffersWithDamageKHR` on type `&api::egl::egl::Egl`
   --> /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/glutin-0.27.0/src/api/egl/mod.rs:621:17
    |
621 |         if !egl.SwapBuffersWithDamageKHR.is_loaded() {
    |                 ^^^^^^^^^^^^^^^^^^^^^^^^ method, not a field
    |
help: use parentheses to call the method
    |
621 |         if !egl.SwapBuffersWithDamageKHR(_, _, _, _).is_loaded() {
    |                                         ++++++++++++

error[E0615]: attempted to take value of method `SwapBuffersWithDamageKHR` on type `&api::egl::egl::Egl`
   --> /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/glutin-0.27.0/src/api/egl/mod.rs:664:13
    |
664 |         egl.SwapBuffersWithDamageKHR.is_loaded()
    |             ^^^^^^^^^^^^^^^^^^^^^^^^ method, not a field
    |
help: use parentheses to call the method
    |
664 |         egl.SwapBuffersWithDamageKHR(_, _, _, _).is_loaded()
    |                                     ++++++++++++

Some errors have detailed explanations: E0599, E0615.
For more information about an error, try `rustc --explain E0599`.
error: could not compile `glutin` due to 3 previous errors

is this a bug in gl-rs or did the members turn into functions somehow? Also set_suspend_callback is gone

Hey,

I am not entirely sure how am I supposed to use this if I want to target wasm / webgl only? Can I combine this library with wasm-pack and add some simple dependency to my Cargo.toml and start coding right away? I am also confused what's the difference between this library (assuming the target is webgl) and web-sys with webgl?

Updates the requirements on glutin to permit the latest version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot will not automatically merge this PR because this dependency is pre-1.0.0.