On Sun, 6 Jan 2013 15:04:23 +0900 Carsten Haitzler (The Rasterman) <[email protected]> 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
