Re: [PDCurses] Need with Autotools compilation on X11
On Sun, Jan 17, 2016 at 4:11 AM, anatoly techtonik wrote: > 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? If you're just starting out, it's not unusual to set compiler and platform specific functionality using defines built into the compiler. However, most experienced C/C++ developers consider it bad practice to do so. Instead, they create their own defines to help specify which platforms should use subsets of code that may not be portable. Why go to all this trouble and create defines independent to the compiler and platform? Take a look at some real world examples. What happens when you try to build a library using X11 on Windows, but it hard codes Win32 header files using the compiler's flag to check if you're on a Windows platform. You have to go through and fix every define, because you only want the X11 headers, not the Win32 headers. Cygwin went so far as to remove the Windows define from their compiler so they wouldn't have the issue. However, if you're using X11 on a Windows compiler other than Cygwin and the library or application uses a builtin define, you're stuck fixing every instance of it. I often find myself going in and fixing defines because someone assumed functionality was or wasn't available based on a compiler flag and my compiler doesn't behave the way they assumed. That's typically why using built-in compiler defines to determine what code to use is not considered the best practice. What about when a compiler doesn't support a feature in one version, but does in a later version? Then not only do you need to check the compiler flags for what operating system and what compiler, but also what versions work and what versions don't with a particular feature. What happens when you need to know the sizeof a particular type on a particular system? Do you assume you know what it is based on compiler and platform? How do you know if you're on a 32 or 64 bit system? Do you look for yet more compiler specific defines? What if there aren't any? C libraries like musl went to great lengths not to have any compiler specific defines to let you know that you're working with musl in place of something like glibc or uclibc. The developer wanted to be able to add new features in later versions and discourage developers from hard-coding what works based on compiler specific defines. Things also get complicated if you're building with a cross-compiler. If you check what platform you're on according to the compiler, it might tell you Linux, but you may be building for Windows or an embedded system with DOS or some other platform. If you're familiar with a language like JavaScript, you'll find JavaScript developers solve the issue of platform specific code by using a runtime check to see whether functionality is available. Some developers have taken a similar approach with C/C++. AT&T came up with one configure/build system that does runtime time checks for functionality. Typically however, the most widely adopted methods for checking functionality in C/C++ are systems such as autoconf and cmake. They creates small programs to run to see if a feature is available or if it will fail, to check the size of types, to check what flags work if a library is available, etc. So basically it's doing a runtime check. The information gathered from these runtime checks can be used to create defines or select what code is used when the program is built. So build systems for most C/C++ programs check for runtime functionality during the build instead of having the programs check when they're run. It's usually much faster for a program to do the check ahead of time and use the information in the compile than to try to check everything dynamically at runtime. It's also easier for the developer if the build tool simply checks if the code works or not on a platform rather than the developer trying to code in every possible combination of which compiler specific flags might be available and in what combination to determine how to do with code that might not be portable. It would be much simpler if developers stuck with code that was portable to all systems, but in practice, this usually only happens for very small sample programs. Even command line tools like many of the common GNU command line utilities (find, ls, etc.) use a lot of platform specific code that's not part of the official C language specifications. There are several extensions to the C language such as the POSIX standards. Many of
Re: [PDCurses] Need with Autotools compilation on X11
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.
Re: [PDCurses] Need with Autotools compilation on X11
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.
Re: [PDCurses] Need with Autotools compilation on X11
On Tue, Jan 12, 2016 at 3:54 PM, LM wrote: > CDetect Does that thing require installation of new tool? -- anatoly t.
Re: [PDCurses] Need with Autotools compilation on X11
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
Re: [PDCurses] Need with Autotools compilation on X11
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. Cheers Mark Maybe it could be just updated to latest version? It seems like this logic is static and doesn't depend on installed libraries. Am I right?
Re: [PDCurses] Need with Autotools compilation on X11
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.
Re: [PDCurses] Need with Autotools compilation on X11
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`"
Re: [PDCurses] Need with Autotools compilation on X11
On Mon, Jan 11, 2016 at 2:27 AM, anatoly techtonik wrote: > On Mon, Jan 11, 2016 at 12:15 AM, William McBrine wrote: >> ./configure --x-libraries=/usr/lib/x86_64-linux-gnu > > This works. https://travis-ci.org/techtonik/PDCurses/builds/101480507 But it is still unclear why autotools don't autodetect these. I forwarded the question to http://lists.gnu.org/archive/html/autoconf/ - let's hope it gets through spam filters. -- anatoly t.
Re: [PDCurses] Need with Autotools compilation on X11
On Mon, Jan 11, 2016 at 12:15 AM, William McBrine wrote: > ./configure --x-libraries=/usr/lib/x86_64-linux-gnu This works. https://travis-ci.org/techtonik/PDCurses/builds/101480507
Re: [PDCurses] Need with Autotools compilation on X11
On Sun, Jan 10, 2016 at 8:47 PM, Richard S. Gordon wrote: > You might find the following lead useful: > > http://packages.ubuntu.com/source/precise/libxaw These are both installed. See https://travis-ci.org/techtonik/PDCurses/builds/101423050#L115 $ sudo apt-get install -y libxaw7 libxaw7-dev -- anatoly t.
Re: [PDCurses] Need with Autotools compilation on X11
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.
