view release on metacpan or  search on metacpan

Makefile.PL  view on Meta::CPAN

printf $ESQLINFO "%s%s ESQLC_IFX_LOC_T;\n", '$', $ifx_loc_t;
$opts{DEFINE} .= " -DESQLC_IFX_LOC_T" if ($ifx_loc_t eq "define");
close $ESQLINFO or die "Failed to write $infofile\n";
print "$infofile written OK\n\n";
}

# Add extra definitions to compile the code under GCC if DBD_INFORMIX_DEBUG_GCC set.
# Perl configuration headers contain lots of /* inside comments (-Wno-comment)
#$opts{DEFINE} .= ' -Wall -pedantic -Wno-comment -Wpointer-arith -Wcast-align'
#       . ' -Wconversion -Wtraditional -Wcast-qual'
#       . ' -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decl'
# Neither Perl (DBI) nor DBD-Informix is really ready for -Wextra.
$opts{DEFINE} .= ' -Wall -pedantic -Wextra -Wno-comment'
    if $Config{cc} eq 'gcc' and $ENV{DBD_INFORMIX_DEBUG_GCC};

# Workaround Informix bug B08223 (aka B14937, and other numbers too)
# AIX localedef31.h defines a loc_t and is used by some system headers.
# Informix locator.h also defines a loc_t.  The workaround is to prevent
# the localedef31.h declaration from being included.
if ($Config{osname} eq 'aix' && !defined $ENV{DBD_INFORMIX_AIX_NO_LOCALEDEF})
{
    $opts{DEFINE} .= " -D__H_LOCALEDEF";
    print nlws('
        Classically, on AIX (only) it has been necessary to define
        -D__H_LOCALEDEF on the command line to avoid the problem with
        loc_t being defined in both ESQL/C header locator.h and the AIX
        system header localedef31.h.  Some newer versions of CSDK may
        require this define to be absent.  The configuration has just
        added the define, so if you get compilation errors related to
        loc_t, reconfigure with $DBD_INFORMIX_AIX_NO_LOCALEDEF set to 1
        in your environment.  This should suppress the -D__H_LOCALEDEF
        and allow things to work OK.  If you use this, and especially
        if neither mechanism works, please let the maintenance team
        know all the details, especially the version of CSDK.
    ');
}

my $objects = "Informix.o dbdimp.o dbdattr.o sqltoken.o";
$objects .= " sqltype.o ixblob.o odbctype.o kludge.o link.o esqlcver.o $vercode.o";
$objects .= " eprintf.o" if defined $ENV{DBD_INFORMIX_USE_EPRINTF_CODE};
if (defined $ENV{DBD_INFORMIX_AUXILLIARY_OBJECT_FILES})
{
    my ($list) = $ENV{DBD_INFORMIX_AUXILLIARY_OBJECT_FILES};
    $objects .= " $list";
    print 'Using auxilliary object files from $DBD_INFORMIX_AUXILLIARY_OBJECT_FILES:';
    $list =~ s/^\s+//;
    $list =~ s/\s+$//gm;
    $list =~ s/\s+/\t\n/gm;
    print "\n\t$list\n\n";
}
# Map object file names on non-Unix platforms
$objects =~ s/\.o\w/$objext/g if ($objext ne ".o");

# Need to pick up the DBI headers.  The DBI headers might be in
# $INSTALLARCHLIB rather than $INSTALLSITEARCH.  This is the case under
# Debian, according to Roderick Schertler <roderick@argon.org>, 1999-09.
# May also, or instead, need -I\$(SITEARCHEXP)/auto/DBI; this was
# reported by Joachim Schrod <jschrod@acm.org> in January 1998 on AIX.
# And on 2002-07-03, Roderick Schertler also reported that we may need
# INSTALLVENDORARCH sometimes (Debian again), and gave the join/map
# formulation without listing SITEARCHEXP.  On my Solaris 7 box with my
# build of Perl 5.8.0, INSTALLVENDORARCH is empty, and SITEARCHEXP is
# the same as INSTALLSITEARCH, but that doesn't do any harm.
#
# ??Should we use $Config{installarchlib} etc, and check for what exists?
# ??Can we sensibly check for uniqueness of directory names?
my $INC2 = join ' ', map { "-I\$($_)/auto/DBI" }
            qw (INSTALLARCHLIB INSTALLSITEARCH INSTALLVENDORARCH SITEARCHEXP);

# Can we find the auto/DBI directory anywhere in @INC?
my $INC3 = join ' ', map { -d "$_/auto/DBI" && "-I$_/auto/DBI" || "" } @INC;

$opts{INC} .= " $INC1 $INC2 $INC3";
$opts{OBJECT} = $objects;

##############################
# - Start of ESQLTEST code - #
##############################

my $unsuccessful_test = qq%
The test program esqltest compiled successfully (which is good).
However, it did not run successfully (which is bad).

If the esqltest program did not produce any output:
    This suggests that there is a problem with the ESQL/C runtime
    environment, or with the database permissions (in which case, you
    should have seen diagnostics from the esqltest program itself).
    Consider whether the shared library path environment variable (eg
    LD_LIBRARY_PATH or SHLIB_PATH) is set correctly.

If the esqltest program did produce some output:
    This suggests that you do not have enough permissions in your
    Informix environment.  You really need DBA (at least RESOURCE)
    level privileges on the database you are using.

If you might be having problems with ESQL/C, try to compile and run
the simple ESQL/C program esqlbasic.ec, which has no Perl related
code in it at all -- it is a pure ESQL/C program:

        esql -o esqlbasic esqlbasic.ec && esqlbasic

If you cannot get that to work, then the problem is with ESQL/C
and not with $opts{NAME} per se, and you need to get your ESQL/C
installation fixed so that you can compile and run the esqlbasic
program successfully.

Make sure you read the whole README file before asking the DBI/DBD
community for help!
%;

# Remove leading and trailing white space
# Michael Lieman <michael.lieman@bankofamerica.com>
# Günther Seifert <guenther-h.seifert@t-systems.com>
sub trim
{
    my($str) = @_;
    $str =~ s/^\s+//;
    $str =~ s/\s+$//;
    return($str);
}