Re: [PDCurses] Need with Autotools compilation on X11

[LM]

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

Re: [PDCurses] Need with Autotools compilation on X11

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

Re: [PDCurses] Need with Autotools compilation on X11

[LM]

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

[anatoly techtonik]

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

[Richard S. Gordon]

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.