On Sun, Jan 17, 2016 at 4:11 AM, anatoly techtonik
On Thu, Jan 14, 2016 at 4:26 PM, LM
wrote: > On Wed, Jan 13, 2016 at 5:23 PM, anatoly techtonik > wrote: >> On Tue, Jan 12, 2016 at 3:54 PM, LM wrote: >>> CDetect >> >> Does that thing require installation of new tool? > > No just 3 include files (C files). One could even possibly distribute > them with pdcurses if desired. Correct me if I wrong, but this is a ./configure done in C? And actually I don't understand what "a tool to help you configure projects" really means, because I am not familiar with autoconf (that's why I asked the question in the first place). So I see that C files already have #define mechanism inside, but it looks like C compilers can not agree what #define's to set and what do they mean. That's why users need to create #defines themselves and define the meaning for them. Am I right? Is there any attempt to define standard set for those #define's and their meaning across compilers? Then tools like autoconf are used to detect which #define is correct for specific system and set its value accordingly. Right? This is made by perl script named ./configure. Right? What is the role of cDetect then? Is it a C program that does the job of Perl ./configure? -- anatoly t.
On Mon, Jan 11, 2016 at 10:15 PM, Mark Hessling wrote: > That would be me. Remember at the time I did the X11 port autotools were > quite primitive. Maybe it is time to replace a lot of the custom autotools > stuff with more standard procedures. Relating my own experiences, I've been switching applications and libraries to use CDetect, make and pkgconf instead of the standard GNU autotools or cmake. I find that much easier to work with than the many other build options I've been researching and trying. There is some basic documentation at: https://github.com/IngwiePhoenix/cDetect/wiki/Documentation:-The-general I have several patches to CDetect to work with pkg-config and provide other features I needed. They may eventually get integrated into this version ( https://github.com/IngwiePhoenix/cDetect ) of CDetect as well. You can find a link to my patches for CDetect at http://www.distasis.com/cpp/lmbld.htm. Just click on the archive link and look for the files with cdetect in their name. The original source I'm using is in the file: cdetect-git-8245c9591104ce4541e6dc6d2f4be041d9970a8b.zip. My build files and patches are in cdetectbld.zip. A Windows (mingw and msys) build script (shell script) generated from my build files is in cdetectbldmingw.zip. It creates a tarball ( cdetect-20100612-i686-1w32.tgz ) with files ready to install (using package manager or general extraction tools like tar or 7zip) on my system. Once the Win32 updates get added into the latest version of pdcurses, I'll look into updating my SDL2 patches to work with the latest version of pdcurses and will try to submit those patches. I've been using them on and off for a while now and they seem stable. Also, I've been doing some testing of libmenu and libform. May still need patching in some areas and there are some differences between applications using ncurses with built in libmenu/libform support and applications using pdcurses with libmenu and libform. So, you can't typically take an application using libmenu, libform and ncurses and port to pdcurses without a few modifications necessary. However, not all ncurses applications work with pdcurses without a few modifications either. Hope to make the code/patches for them available as well. PDCurses SDL2 port and SDL 1.2.x port currently use just a make file with switches. I was considering whether or not to introduce CDetect into the build process. Didn't want to make too much of a change to how things worked though. I could probably create one CDetect program that would work for any of the builds, SDL, SDL2, X11, Win32, Win32 console. Some programs/libraries offer multiple ways to build them using tools such as cmake and GNU autotools. So, if having another build option for pdcurses would be useful, I could write a CDetect/make/pkgconfig option for pdcurses. If this would be useful to anyone besides myself, please let me know. To date, I've been attempting to diverge as little as possible from the official pdcurses code and makefiles. Sincerely, Laura
On Mon, Jan 11, 2016 at 6:11 PM, William McBrine
wrote: > On Mon, Jan 11, 2016 at 6:17 AM, anatoly techtonik > wrote: > >> But it is still unclear why autotools don't autodetect these. > > Well, it goes through the MH_CHECK_X_LIB function in alocal.m4, which > defines the search path like so: > > mh_lib_dirs="$x_libraries `echo "$ac_x_includes $ac_x_header_dirs" | > sed s/include/lib/g`" And who created this aclocal.m4? >From http://stackoverflow.com/a/1971156/239247 it it looks like it is obsolete functionality, but I don't understand what is being replaced with what. Shouldn't locating X11 libs be a common Linux task that doesn't rely on custom macros? BTW, the message is posted, waiting for reply: http://lists.gnu.org/archive/html/autoconf/2016-01/threads.html -- anatoly t.
You might find the following lead useful: http://packages.ubuntu.com/source/precise/libxaw Dick Gordon > On Jan 10, 2016, at 11:28 AM, anatoly techtonik
wrote: > > Hi, > > Are there any autotools experts here to say what should be > done to debug this failure? > > https://travis-ci.org/techtonik/PDCurses/builds/101423050 > > -- > anatoly t.