Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable egl-only (x11-less) builds / configure option --disable-glx #52

Closed
wants to merge 2 commits into from
Closed

Conversation

schnitzeltony
Copy link

No description provided.

Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com>
this option would help us in yocto to get deterministic build results

Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com>
@anholt
Copy link
Owner

anholt commented Jun 6, 2015

One of my goals of libepoxy is to not have configuration (you can drop the generated code right into your private repository and build statically with no extra work, hopefully). GLX costs only 20kb of built code and no library dependencies, which I think is not worth having ABIs to conflict in the shared-library case, either.

@rossburton
Copy link
Contributor

It does cost library dependencies - libx11 is a build dependency. Our meta-distro has a distro-wide "enable X11" toggle and if that is disabled libx11 refuses to build.

@tnn2
Copy link

tnn2 commented Sep 14, 2015

Hi,
The lack of an option to toggle glx has also caused trouble for pkgsrc/OSX users:
See bug report pkg/50238
Please consider to add a configure option to toggle this. Thanks!

@gdt
Copy link

gdt commented Sep 14, 2015

I also ran into the problem in pkgsrc. I think the basic issue is that a library like libepoxy should provide a consistent set of interfaces that don't change based on the system it's being built on, at least not automatically. On OSX, whether X11 is present or not depends on your attitude about what ought to be and if you have installed XQuartz. Declining to provide glx results in a libepoxy that is defective from the gtk3 viewpoint.

It may be that the right fix is to have wrappers for things that don't depend on X and separate wrappers for things that do, so that one can depend on both if that's what is necessary.

I agree that having configure options is better than the current state; packaging systems can decide what they are going to have libepoxy depend on and configure on/off the related support.

@yaronct
Copy link
Contributor

yaronct commented Sep 14, 2015

@schnitzeltony, @rossburton, @tnn2, @gdt: Feel free to use my fork ("master" branch). It can be built also using CMake, with various options, including to disable GLX. It also doesn't depend on the EGL headers for EGL support, and has various other fixes, especially for EGL and for Windows.

@jeremyhu
Copy link

Please pull this into master. As mentioned above, libepoxy is a dependency of gtk3. gtk3 can be built with either X11 or Quartz backends on OSX, but libepoxy does not support GLX on OSX out of the box (previously, it was forced on, now it's forced off).

@jeremyhu
Copy link

Actually, hold off. It turns out that this patch doesn't actually work. Adding --enable-glx doesn't actually enable glx ;) I'll send another pull request with fixups.

jeremyhu added a commit to jeremyhu/libepoxy that referenced this pull request Jan 18, 2016
Followup for anholt#52

Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
@rossburton
Copy link
Contributor

Any chance of this or similar being merged? It would be so nice to be able to build GTK+3 without needing X11 to be present.

@sardemff7
Copy link

Any news on these?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants