run minimum_script4gdl.sh and quick_start_GDL.sh on Travis

[slayoo]

[alaingdl]

what do you mean ? Isn't it self explanatory ?

[slayoo]

My first ever try with it today resulted in:

$ ./quick_start_GDL.sh
bash: ./quick_start_GDL.sh: Permission denied

:)

[slayoo]

minimal_script worked OK My point is basically to detect early if something external breaks such builds

[alaingdl]

Yes, long story ... was a time on SF with CVS ... difficult/impossible to change mode ...

$ chmod 755 quick_start_GDL.sh
$ ./quick_start_GDL.sh

or

$ sh quick_start_GDL.sh

I don't if we can change that in Git ?!

What is convenient for me is you can run if from anywhere with the good local sud-dirs:

sh ~/GDL/gdl-1.0.0rc2-git200619CMake/quick_start_GDL.sh

and I can run in parallel another GDL to make cross-cheks.

It is also a way for beginners to have the good paths in GDL_PATH without editing something

[slayoo]

As we've noticed in #803, we could also test behaviour on a very bare system without curses and other basic libraries

[GillesDuvert]

see my comment in https://github.com/gnudatalanguage/gdl/discussions/889#discussioncomment-494916

[GillesDuvert]

As .ci/build_gdl.sh now is able to build full-fledged GDL on any machine, I propose to stop maintaining all other scripts, such as quick_start_GDL.sh, in favor of the only one (build_gdl.sh) that is tested everyday in the GH builds. And closing all the issues related to those unsupported scripts, that add only confusion now. I wll do this at once. It is also needed that the documentation (GH Wiki but also Alain's pages) are updated to make reference only to build_gdl.sh. And that we agree of course that we maintain and make better build_gdl.sh, that is a strongly structured script easy to maintain.

[alaingdl]

Ha ha, we were discussing on that this morning with @eloirozier and it is obviously YES but before talking here on that I made some tests and I did had some troubles : -- this new script is not working on OSX 10.14.6

    clang-11: error: linker command failed with exit code 1 (use -v to see invocation)

-- this script is KO on some Debian around

  File "<string>", line 1
    import numpy; print(numpy.get_include(), end='')
                                                ^
SyntaxError: invalid syntax
CMake Error at CMakeLists.txt:920 (message):
  Python numpy package was not found.

  Use -DPYTHON=OFF to disable Python support.

[alaingdl]

-- another HPC, same kind of problem : need to "module load" the good GCC, the good Cmake, and no way up to now to find a solution for Readline ...

-- another HPC provid only cmake/3.9.4 ...

[GillesDuvert]

@alaingdl this is exactly the purpose: to have all of us amend this one and only script to make it work on all machines. Note that it is not the scrit pthat is KO on debian, but the Cmake. By using the script, that enforces all dependencies (or try to, see HDF4 on macOs) we test all the chain. I reckon the script in its initial phase "prep" does not install the toolchain. It should (gcc, cmake, even antlr3....)

[pjb7687]

Just FYI: The commit 7b48ff5fd6f1e44322d4dfa2fdab0f8718b8b628 adds python3-dev package which is needed to compile GDL on Debian. Just now I confirmed that GDL compiles well on Debian 10, with the CMake from backports:

apt install cmake/buster-backports

[pjb7687]

And I also modified the CMakeLists.txt so that CMake finds Python in a better way (9c1c055063f02c1d06673b2473b0a57ec1c13daf). Formerly it looked a bit weird to me - it tried to find Python twice (firstly with FindPythonInterp, and secondly again with FindPython!), and sometimes the versions are different from each other, which made the compile failure.

I just removed one of them (only using FindPython, the other one is obsolete), and now it seems to work better. I think this also might be the problem that happened on your machines - if you could try compiling the latest commit, it would work now.

[GillesDuvert]

Thanks JeongBin! There may be quite a few issues about CMake (label cmake) that may have been cured now!

ah, as generator expressions seem to be in CMake since 3.0 at least, I will, unless told differently, revert line 10 in CMakeLists to set cmake_minimum_required(VERSION 3.14 FATAL_ERROR) # 3.14: required for finding numpy (this one is for sure).

[pjb7687]

@GillesDuvert Indeed I misread the CMake manual. Thanks!