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 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 \ Index: src/Makefile_Evas.am 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 > > -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ 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
