make install with extensions fails about flint2 HOT 7 CLOSED

As far as I remember BASH specification, construct [ -z smth ] and [ ! -z smth ] is illegal if smth is a string with spaces. Such problems are usually fixed with double-quotes ". I am however unsure how bash evaluates string like $(EXT_HEADERS) because according to man page of bash, $(smth) means run command smth and take its stdout.

I think that cp command will fail if $(DESTDIR) evaluates to string with spaces.

I wrote and browsed many ebuild scripts (which are by definition bash scripts) and 100% sure that constructs

cp $file $dir/$file_dest

should always come with double-quotes:

cp $file "$dir/$file_dest" or cp $file "$dir"/"$file_dest"

from flint2.

created ebuild to build FLINT with BLAND extension. Result: success (created .so contains extension subroutines _elem*), file-name: https://github.com/krisk0/razin/blob/master/ebuild/flint-2.4.3-r1.ebuild

created ebuild to build FLINT with BLAND and ANTIC extensions. Result: failure (build process terminates successfully but does not attempt to build any extension; -I set to a stupid value), file-name: https://github.com/krisk0/razin/blob/master/ebuild/flint-2.4.3-r2.ebuild

I also noticed that configure/make does not support space in either build dir or dest dir (at least make quickly terminates if build dir has space inside)

from flint2.

Are you putting double quotes around the list of extension paths, e.g.

--extensions="/path/to/bland /path/to/antic"

It definitely needs them. However, I am not sure if I've tried to do this
myself, so I don't know for sure if it works.

Bill.

On 14 April 2014 12:50, Денис Крыськов (Denis Kryskov) <
[email protected]> wrote:

created ebuild to build FLINT with BLAND extension. Result: success
(created .so contains extension subroutines _elem*), file-name:
https://github.com/krisk0/razin/blob/master/ebuild/flint-2.4.3-r1.ebuild

created ebuild to build FLINT with BLAND and ANTIC extensions. Result:
failure (build process terminates successfully but does not attempt to
build any extension; -I set to a stupid value), file-name:
https://github.com/krisk0/razin/blob/master/ebuild/flint-2.4.3-r2.ebuild

I also noticed that configure/make does not support space in either build
dir or dest dir (at least make quickly terminates if build dir has space
inside)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/62#issuecomment-40353553
.

from flint2.

In 2nd ebuild (that does not work), of course, yes, because there are 2 directories:

with_ext="--extensions=\"$WORKDIR/bland-master $WORKDIR/antic-trunc\""
./configure \
    "$with_mpir"\
    "$with_ext"\
    --with-mpfr="$EPREFIX/usr"\
...

Putting douible-quotes into 1st ebuild breaks it: the thing pretends to work, but never attempts to build extension, and resulting .so does not contain any subroutine _elem...

Lines that work and build extension:

with_ext="--extensions=$WORKDIR/bland-master"
./configure \
    "$with_mpir"\
    "$with_ext"\
    --with-mpfr="$EPREFIX/usr"\

IMHO foreach directive in Makefile is the problem

from flint2.

As far as I remember BASH specification, construct [ -z smth ] and [ ! -z smth ] is illegal if smth is a string with spaces. Such problems are usually fixed with double-quotes ". I am however unsure how bash evaluates string like $(EXT_HEADERS) because according to man page of bash, $(smth) means run command smth and take its stdout.

$(EXT_HEADERS) is expanded by make, not the shell.

The shell (whether bash or some other shell) doesn't care either; [ is an alias for test, an external program. To be on the safe side, in [ -z $var ] the variable should always be quoted.

In Sage, currently the following patch gets applied:

commit 81c820b73dc0208f107629d7658f4f0642ca64e8
Author: Jean-Pierre Flori <[email protected]>
Date:   Mon Feb 3 15:02:22 2014 +0100

    Fix test for empty string in install target.

diff --git a/Makefile.in b/Makefile.in
index 0fa717b..19caed2 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -178,7 +178,7 @@ install: library
        cp libflint.a $(DESTDIR)$(PREFIX)/lib; \
    fi
    cp $(HEADERS) $(DESTDIR)$(PREFIX)/include/flint
-   $(AT)if [ ! -z $(EXT_HEADERS) ]; then \
+   $(AT)if [ ! -z "$(EXT_HEADERS)" ]; then \
        cp $(EXT_HEADERS) $(DESTDIR)$(PREFIX)/include/flint; \
    fi
    mkdir -p $(DESTDIR)$(FLINT_CPIMPORT_DIR)

from flint2.

In my humble opinion this patch is useless because either make variable EXT_HEADERS is evil and cp $(EXT_HEADERS) ... will fail, or EXT_HEADERS is good and everything is fine, with or without patch

from flint2.

This patch has now been applied in the repository and will make it into flint-2.5.

from flint2.