make x11 support optional #1
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
These have dlsym versions of GLIBC_2.3 and GLIBC_2.2, respectively. Signed-off-by: Adam Jackson <ajax@redhat.com>
If a parent directory of the libepoxy source dir contains a space, 'cd' in line 10 fails.
Client extensions are always available, and are only listed in eglQueryString(dpy=NULL). Without this we can't call anything from e.g. EXT_platform_base. Signed-off-by: Adam Jackson <ajax@redhat.com>
Binding an API does not change the type of the current context. Even if it did, EGL 1.5 treats EGL_OPENGL_API and EGL_OPENGLES_API as identical for this purpose. If you want to know properties of the current context, query it. Signed-off-by: Adam Jackson <ajax@redhat.com>
Most of the changes that happened after commit 8bbc0d4 broke epoxy pretty much irreparably because of the CMake build and the attempt at making libepoxy a static library that can be copy-pasted into another project without generating files. Since all the commits are entangled, and are full of unrelated changes, we cannot simply do a localized set of reverts; instead, we need to hit the reset button. From this point forward, we're going to improve libepoxy's build while attempting to keep the existing build system working. This may mean reinstating the CMake build system at a later date.
...so that the generated code are buildable by pre-2013 Visual Studio. The main thing that this does is that we avoid named initializers, but instead initialize the structs in old-school C89 way. The generated code may not look that robust, but since this is generated code, I think this is not that much an issue; when the Khronos registry gets updated, all that is needed is that the code gets re-generated, and we have the items in the right order. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
The code used to check this symbol, but commit 689abf4 replaced it with GLX_H, presumably to work better with either Mesa or Khronos headers. But nVidia's header use the older include guard. Add it as another option. Should fix the headerguards.c compile test when the system glx.h is from nVidia's binary drivers. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
Some X server not supporting any OpenGL feature, glXQueryExtensionsString will return NULL and causes the function to fail. Thanks to Emmanuel Stapf (manus@eiffel.com) for the original patch. This was verified running an application on macOS while the X server was running on Windows Xming 7.5.0.10 Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
See sysdeps/unix/sysv/linux/arm/libdl.abilist in glibc Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
The rest of the library is C89-only, so we should keep it that way.
Closes PR: anholt#83
Completes commit 83cfa6a.
Closes PR: anholt#75 Conflicts: test/dlwrap.c
The gen_dispatch.py script relies on the source and include directories to exist before dumping the files in there, split by type, in order to sustain the split of the headers existing in a separate root from the source files. This causes a spooky-action-at-a-distance scenario where headers are generated by rules inside the source directory but influence the contents of a separate directory — and require a separate set of rules to install those headers. Different build systems would require either splitting the generation in to two separate passes (which is more expensive and time consuming), or generate the header and source files in the same directory, and just tweak the inclusion paths accordingly. Since we want to maintain this fiction for the autotools build, but ignore it for different build systems, let's add a separate set of arguments for gen_dispatch.py that make the rules inside Makefile.am work appropriately.
Meson is a Python-based build system that generates build rules of Ninja, Visual Studio, and XCode. It's designed to be fast, and have a small, non-Turing complete language to describe the build process, tests, and dependencies. It's simpler than CMake, and faster than autotools. As a direct comparison in terms of speed, three build and check runs for libepoxy from a clean Git repository clone yield these results on my Kabylake Core i7 7500U (nproc=4): - Autotools (make) Run #1 (cold) real: 22.384s, user: 20.011s, sys: 3.689s Run anholt#2 (warm) real: 22.429s, user: 20.220s, sys: 3.708s Run anholt#3 (warm) real: 22.068s, user: 19.743s, sys: 3.594s - Meson (ninja) Run #1 (cold) real: 5.932s, user: 9.371s, sys: 1.625s Run anholt#2 (warm) real: 6.273s, user: 10.066, sys: 1.740s Run anholt#3 (warm) real: 5.796s, user: 9.233s, sys: 1.607s Which means that Meson and ninja are approximately 4x faster than autotools. In terms of simplicity, the autotools build takes six files and a total of 645 lines; Meson requires 3 files, and 361 lines to achieve the same result. Additionally, Meson automatically builds in a separate build directory and does not leave files inside the source directory; and Meson does not use libtool. Since Meson is quite new and still actively developed, we're going to leave the autotools build in place for a while, with the intention of switching to Meson in the future.
This maintains the compatibility between the autotools-based build and the Meson one, mirroring commit 037ac7f.
Meson adds `-Wall` for us with `warning_level=1`.
There's no need to use a leading '/' for the constant chunk, and we should use the same style consistently.
it seems like this was forgotten, because glBindFramebufferEXT is already there for the same reason Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
It's possible to tell Meson to build a static library, instead of a shared one, using a command line option.
We already know the Microsoft Visual C compiler does not support `-Bsymbolic`.
Certain X server do not have GLX enabled or supported, such as x2go. We can handle this case gracefully inside libepoxy. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
X11 support is build by default if x11 libs are found. This can be disabled by --disable-glx. A similar (bit too overenthusiastic) pull request was sent long time ago [1] before we saw cmake trouble. There was a follow up PR in [2] but I cannot test it so took only very common parts. [1] anholt#52 [2] anholt#81 Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com>
|
Thanks for the PR; I'm in the process of trying to my branch merged back into the original repository. Additionally, I'd like to switch to Meson as the default build system — with autotools as the fallback for a while. The PR looks good, and I'm going to try an merge it soon-ish. Thanks again! |
ebassi
added a commit
that referenced
this pull request
Jan 18, 2017
Meson is a Python-based build system that generates build rules of Ninja, Visual Studio, and XCode. It's designed to be fast, and have a small, non-Turing complete language to describe the build process, tests, and dependencies. It's simpler than CMake, and faster than autotools. As a direct comparison in terms of speed, three build and check runs for libepoxy from a clean Git repository clone yield these results on my Kabylake Core i7 7500U (nproc=4): - Autotools (make) Run #1 (cold) real: 22.384s, user: 20.011s, sys: 3.689s Run anholt#2 (warm) real: 22.429s, user: 20.220s, sys: 3.708s Run anholt#3 (warm) real: 22.068s, user: 19.743s, sys: 3.594s - Meson (ninja) Run #1 (cold) real: 5.932s, user: 9.371s, sys: 1.625s Run anholt#2 (warm) real: 6.273s, user: 10.066, sys: 1.740s Run anholt#3 (warm) real: 5.796s, user: 9.233s, sys: 1.607s Which means that Meson and ninja are approximately 4x faster than autotools. In terms of simplicity, the autotools build takes six files and a total of 645 lines; Meson requires 3 files, and 361 lines to achieve the same result. Additionally, Meson automatically builds in a separate build directory and does not leave files inside the source directory; and Meson does not use libtool. Since Meson is quite new and still actively developed, we're going to leave the autotools build in place for a while, with the intention of switching to Meson in the future.
|
I've fixed this in a slightly different way in the disable-glx branch. |
ebassi
added a commit
that referenced
this pull request
Jan 25, 2017
Meson is a Python-based build system that generates build rules of Ninja, Visual Studio, and XCode. It's designed to be fast, and have a small, non-Turing complete language to describe the build process, tests, and dependencies. It's simpler than CMake, and faster than autotools. As a direct comparison in terms of speed, three build and check runs for libepoxy from a clean Git repository clone yield these results on my Kabylake Core i7 7500U (nproc=4): - Autotools (make) Run #1 (cold) real: 22.384s, user: 20.011s, sys: 3.689s Run anholt#2 (warm) real: 22.429s, user: 20.220s, sys: 3.708s Run anholt#3 (warm) real: 22.068s, user: 19.743s, sys: 3.594s - Meson (ninja) Run #1 (cold) real: 5.932s, user: 9.371s, sys: 1.625s Run anholt#2 (warm) real: 6.273s, user: 10.066, sys: 1.740s Run anholt#3 (warm) real: 5.796s, user: 9.233s, sys: 1.607s Which means that Meson and ninja are approximately 4x faster than autotools. In terms of simplicity, the autotools build takes six files and a total of 645 lines; Meson requires 3 files, and 361 lines to achieve the same result. Additionally, Meson automatically builds in a separate build directory and does not leave files inside the source directory; and Meson does not use libtool. Since Meson is quite new and still actively developed, we're going to leave the autotools build in place for a while, with the intention of switching to Meson in the future.
|
I lost overview a bit: Is it possible that disable-glx branch did not find it's way to master? |
|
Yes, I haven't merged it yet, as I had a couple more branches to land first. I'll make sure to land it and then do a 1.4 release of libepoxy. |
|
I've pushed the I think we can close this PR. Thanks again for your contribution, and sorry for taking this long. |
|
I've already build tested 1.4.0 -> close is fine
Thanks for taking care of libepoxy
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
X11 support is build by default if x11 libs are found. This can be disabled
by --disable-glx.
A similar (bit too overenthusiastic) pull request was sent long time ago [1]
before we saw cmake trouble. There was a follow up PR in [2] but I cannot test
it so took only very common parts.
[1] anholt#52
[2] anholt#81
Signed-off-by: Andreas Müller schnitzeltony@googlemail.com