On Mon, 7 Jan 2013 20:39:26 -0200 Gustavo Sverzut Barbieri <barbi...@profusion.mobi> wrote:
> Hi Joel, > > This looks fine, one last question: why are these needed? > > =================================================================== > --- src/Makefile_Ecore_Evas.am (revision 82364) > +++ src/Makefile_Ecore_Evas.am (working copy) > @@ -74,7 +74,8 @@ > -I$(top_srcdir)/src/lib/ecore_x \ > -I$(top_builddir)/src/lib/ecore_x \ > -I$(top_srcdir)/src/modules/evas/engines/software_x11 \ > --I$(top_srcdir)/src/modules/evas/engines/gl_x11 > +-I$(top_srcdir)/src/modules/evas/engines/gl_x11 \ > +@ECORE_X_CFLAGS@ > modules_ecore_evas_engines_x_module_la_LIBADD = \ > lib/ecore_evas/libecore_evas.la \ > lib/ecore_x/libecore_x.la Without this I get: In file included from modules/ecore_evas/engines/x/ecore_evas_x.c:22: ../src/modules/evas/engines/gl_x11/Evas_Engine_GL_X11.h:4:10: fatal error: 'X11/Xlib.h' file not found I assume this is the one you found. > Index: src/Makefile_Ecore_Imf.am > =================================================================== > --- src/Makefile_Ecore_Imf.am (revision 82364) > +++ src/Makefile_Ecore_Imf.am (working copy) > @@ -155,7 +155,8 @@ > -I$(top_builddir)/src/lib/ecore_x \ > -I$(top_srcdir)/src/lib/ecore_imf \ > @ECORE_IMF_CFLAGS@ \ > -@EFL_COV_CFLAGS@ > +@EFL_COV_CFLAGS@ \ > +@ECORE_X_CFLAGS@ > modules_ecore_immodules_xim_xim_la_LIBADD = \ > lib/ecore_imf/libecore_imf.la \ > lib/ecore_x/libecore_x.la \ Without this I get: modules/ecore/immodules/xim/ecore_imf_xim.c:10:10: fatal error: 'X11/Xlib.h' file not found > > both ecore_evas and imf shouldn't be doing X directly, rather using > Ecore_X that shouldn't expose X directly. A quick look tells me that > ecore-evas is including X directly for some weird reason I'll try to > investigate. But how about IMF? > > > On Mon, Jan 7, 2013 at 8:02 PM, Joel Klinghed <the...@spawned.biz> > wrote: > > > On Mon, 7 Jan 2013 19:25:22 -0200 > > Gustavo Sverzut Barbieri <barbi...@profusion.mobi> wrote: > > > > > Hi Joel, > > > > > > Just go to this mail, did you try that with SVN EFL (trunk, single > > > tree)? I'm trying to get it right for release 1.8, so if you find > > > something that applies there, let me know. > > > > > > From memory the XTRA stuff should also be wrong, if you send the > > > patch I'll apply. > > > > Yes I did, most of the missing CFLAGS & LIBS handling from evas > > 1.7.x was copied over to merged trunk efl. > > > > Attached is an updated patch based on r82364 that includes what I > > need to be able to compile efl with either x11 or xcb backend > > including GL without modifying environment variables. > > > > But the whole patch builds on the premise that AC_PATH_X and > > AC_PATH_XTRA gives correct results. > > > > For old (pre modular Xorg) X11 this is not a problem, AC_PATH_X uses > > xmkmf to get include and lib directories (or uses the --x-includes, > > --x-libraries arguments given to configure). > > For modern X11 the whole Imakefile system is probably missing > > (including xmkmf). Some distros do what I do, create a fake xmkmf > > that just returns what AC_PATH_X needs. Some modify AC_PATH_X to use > > pkg-config. A lot just put everything in /usr/include. I do > > not pretend to know what all of them do... > > > > To put it another way, my patch tries to unify the flags used in the > > configure checks and the flags used in the compilation. Without the > > patch the compilation uses the results of AC_PATH_X but the > > configure checks do not. > > > > /JK > > > > > On Sun, Jan 6, 2013 at 8:54 AM, Joel Klinghed <the...@spawned.biz> > > > wrote: > > > > > > > On Sun, 6 Jan 2013 15:04:23 +0900 > > > > Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote: > > > > > > > > [snip] > > > > > > > > > > > > > > > > > > > > > * evas-1.7.2-configure-xorg.patch > > > > > > > > > > Use X_CFLAGS when checking X11 and GL headers and > > > > > > > > > > X_LIBS when checking X11 and GL libs. > > > > > > > > > > Also use X_CFLAGS when compiling gl_common as GL > > > > > > > > > > headers might use the same prefix. > > > > > > > > > > > > > > > > > > ummm configure.ac is a lot different now... try again? > > > > > > > > > > > > > > > > I've included an patch for the merged efl tree. > > > > > > > > Also an updated patch for the evas-1.7 and ecore-1.7 > > > > > > > > branches. > > > > > > > > > > > > > > no ecore one attached. > > > > > > > > > > > > > > so now this is up to date... i'll base my comments on the > > > > > > > efl merged patch. why do you use "X_CFLAGS" and > > > > > > > "X_LIBS" (i also spot X_PRE_LIBS)? are they not > > > > > > > detectable by just modifying your regular CFLAGS and > > > > > > > LDFLAGS before configure is run? why does this need a > > > > > > > special set of env vars? basically - what about the > > > > > > > existing setup is broken/doesnt work right there? i smell > > > > > > > some other issue... > > > > > > > > > > > > Right, forgot the ecore one, included this time. > > > > > > > > > > > > X_CFLAGS, X_LIBS, X_PRE_LIBS and X_EXTRA_LIBS are all set by > > > > > > AC_PATH_XTRA. So not env vars. > > > > > > They are more or less what x_cflags and x_libs ends up > > > > > > being. > > > > > > > > > > > > AC_PATH_X on the other hand sets x_includes and x_libraries. > > > > > > > > > > > > I could have used x_includes and x_libraries instead but > > > > > > then I would had to move the header and lib checks below > > > > > > the x_lib, x_cflags, x_libs calculations as I don't want to > > > > > > do that work twice. > > > > > > > > > > > > To summarise, my problem is that AC_PATH_X and AC_PATH_XTRA > > > > > > full and well find my X11 path (/usr/xorg as it happens) but > > > > > > the next test AC_CHECK_HEADER([X11/X.h]) fails because it > > > > > > doesn't use any of the results from those macros. > > > > > > > > > > ok... so here´s the question. it seems you are putting xorg > > > > > in its own prefix ala the good old /usr/X11R6 (or /usr/xorg > > > > > now)... which has kind of been dropped as a standard x > > > > > location amongst a lot of distros/os's - why should this be > > > > > handled specially anymore when adding -I/usr/xorg/include and > > > > > -L/usr/xorg/lib to your $CFLAGS and $LDFLAGs (also maybe > > > > > adjust LD_LIBRARY_PATH, PATH and PKG_CONFIG_PATH).. exactly > > > > > like you need to do with every other package you install from > > > > > scratch this is why fribidi was a problem > > > > > - right? u put it in /usr/fribidi or something?) ... ? i'm > > > > > just wondering here why we need to add even more autofluff > > > > > special cases here when it's becoming increasingly less > > > > > common and env vars solve the problem in a ingle universal > > > > > common way for every case like this? :) > > > > > > > > Well, for most packages you have some way of asking where it was > > > > installed so you don't have to write infernal long CFLAGS and > > > > LDFLAGS. You have pkg-config, *-config scripts and so on. > > > > To me, the whole point of checking if and where a package is > > > > installed is so compiling will just work on every dist and OS. > > > > > > > > Old X11 you located by using xmkmf (which is what AC_PATH_X* > > > > does). For Xorg you actually have nice pkg-config files but > > > > they are only used for xcb. > > > > > > > > The thing is, even if I put my Xorg in /usr/X11R6 the configure > > > > check as they are now would not work. They *only* work if > > > > X11/Xlib.h is places in /usr/include or /usr/local/include or > > > > one of the standard includes. Same for libs as both > > > > AC_CHECK_HEADER and AC_CHECK_LIB doesn't use x_includes or > > > > x_libraries that you later use to actually compile everything. > > > > > > > > But yes, it is unusual not to put your X11 files all over /usr > > > > and /usr/X11R6. Perhaps because of all these broken configure > > > > scripts? ;) > > > > > > > > I can take that I'll have to add -I/usr/xorg/include > > > > -L/usr/xorg/lib64 to CFLAGS and LDFLAGS respectively but then I > > > > must ask, why do you bother calling AC_PATH_X and AC_PATH_XTRA? > > > > You don't use it and unless everything is accessible > > > > from /usr/include and /usr/lib anyway it wont work as both the > > > > X11/X.h and XCreateImage in libX11.so checks will fail. > > > > > > > > [snip] > > > > > > > > /JK > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, > > > > CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your > > > > skills current with LearnDevNow - 3,200 step-by-step video > > > > tutorials by Microsoft MVPs and experts. ON SALE this month > > > > only -- learn more at: http://p.sf.net/sfu/learnmore_123012 > > > > _______________________________________________ > > > > enlightenment-devel mailing list > > > > enlightenment-devel@lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills > > current with LearnDevNow - 3,200 step-by-step video tutorials by > > Microsoft MVPs and experts. SALE $99.99 this month only -- learn > > more at: http://p.sf.net/sfu/learnmore_122412 > > _______________________________________________ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
