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. 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 > -- 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
