Load and run a script in Magma; - magma-ca

I am using Magma in Windows (C:\program files\magma).
I have some scripts xyz.m in the D:\scripts directory. I can't figure out how to load the scripts and run them.
Thank you for your help.
Regards

To run magma from any directory under windows. One has to create an environment variable MAGMA_PATH where the value is the directory path of the scripts.

Related

Why can I use CMake supplied modules (CMakeDependentOption.cmake specifically) locally, but not on CI or Docker?

I have a cmake project that successfully builds locally but errors with
include could not find load file:
CmakeDependentOption
when trying to build on a CI platform or in Docker. Note that CMakeDependentOption.cmake is a script that comes with cmake itself. So it should just be available. On CI to install cmake, I wget the relevant cmake release from their downloads page, unzip it and add the bin directory to the PATH environment variable. Then I use the cmake command to build my library. The result is the above error.
I suspect this means that a CMake variable (such as "CMAKE_MODULE_PATH" but not, since this variable seems to be empty at the start of the cmake script) is messed up or not set somehow. The path to the correct file to include is
<cmake_root>/share/cmake-3.18/Modules/CMakeDependentOption.cmake
And I have verified that it exists manually. My question: is there a way to locate this directory from within cmake? Perhaps a cmake --config or cmake --libs mode (a bit like pkg-config?)
Failing that, does anybody have any suggestions as to why this is happening and how to get around it.
You can locally because most likely you don't use a linux based platform, like windows or mac. This is because linux filesystem are case sensitive. Which means CmakeDependentOption is different from CMakeDependentOption.
Docker runs containers in linux, so filenames are gonna be case sensitive, and the include is going to fail if the cases are different.

Building boost - build.bat is not recognized as a program

I am trying to build Boost for using the filesystem library.
I understand that I must run bootstrap.bat (for Windows) to create a b2 application, that should I run after.
But I get this errors:
C:\Users\Andrei>D:\Info\include\boost_1_58_0\tools\build\bootstrap.bat
Bootstrapping the build engine
The system cannot find the path specified.
'.\build.bat' is not recognized as an internal or external command,
operable program or batch file.
Failed to bootstrap the build engine
Please consult bootstrap.log for furter diagnostics.
I haven't find build.bat or the log file..
How can I solve this problem ? I read that I must build it to get filesystem libs. It's this true ?
Thank you very much.
You should cd into the boost build directory before executing bootstrap.bat.
Try
cd D:\Info\include\boost_1_58_0\tools\build\
bootstrap.bat

GDB not a recognized command - Windows command prompt

I am trying to use GDB to debug a C++ program, but my system is not recognizing gdb as a command. I installed it, along with many other tools, via MinGW. I have not had any problem with the other features I have used (gcc, g++), so the issue doesn't seem to be with my general set up. I have added the MinGW\bin directory to my PATH. The gdb.exe is in that folder. But it will not run when invoked from my project directory, it simply errors: "'gdb' is not recognized as an internal or external command, operable program, or batch file." Is there some step in setup or invocation that I missed for using GDB?
EDIT: Alright, I think I found the problem: there are two MinGW directories in my PATH, one at C:\MinGW, and another in folder that got installed with some Haskell compilers I used a while ago. It appears to be defaulting to the Haskell folder, perhaps because this directory is listed first. However, this folder contains gcc and g++, but NOT gdb. I was able to get the gdb command working by creating the fstab file in the msys directory, a step I apparently forgot when setting up MinGW. I added my C:\MinGW directory to it, and now the gdb command is working properly! Out of curiosity, what does this file do?
Also, ideally I would like it to look in the C:\MinGW directory first, since this is the folder I plan to keep updated, and the one that contains ALL of the various applications. However, the Haskell directory is specified via the system PATH variable, which I've read it's not a good idea to touch. Would switching the order that they appear even fix my problem?
EDIT 2: Not 100% sure what happened, but the gdb command appears to be working now. I have always been using the Windows cmd prompt to run these tools, so per the answer below (that I should not need to mess with msys) I deleted the fstab file, and lo, it still works! However, my second question above still stands: What is the best way to get the compilers to run out of C:\MinGW\bin instead of C:\Program Files (x86)\Haskell Platform\2013.2.0.0\bin? Is moving the Haskell location out of the system PATH and to the end of the user PATH a viable option?
I had to run pacman -S mingw-w64-x86_64-gdb separately and then gdb showed up in the bin.
You do not have to run gdb (or gcc and all other MinGW tools for that matter) within msys - it is not like Cygwin in that respect. Had you run it from the Windows cmd console, it should work.
The msys shell is useful for running configure scripts generated by Autoconf used by many Linux originated open source projects, but its environment is independent of the Windows environment.

Use c++ compiled library in virtualenv

Notes
This is a python-2.7/django-1.6 project
I have a project that requires the use of the libRETS C++ library which supports python. I was able to successfully compile so that librets is now in my /usr/local/lib/python2.7/dist-packages using the ./configure, make and make install commands.
Now for the current project I am using a virtualenv and doing development using PyCharm as the IDE. I am not sure how to include this library in my virtual environment. Is there a way to inlcude global site packages in my virtualenv? Do I need to create a symbolic link to the librets files in the dist-packages directory, or should I have specified where the package should be installed when I did the configure command?
Any help or suggestions would be greatly appreciated or if my question is not clear please let me know how I can expound.
I solved this by simply copying librets.* files from my /usr/local/lib... directory directly into my virtualenv dist-packages directory for the project.

Python-dependency, windows (CMake)

I have a large, crossplatform, python-dependent project, which is built by CMake.
In linux, python is either preinstalled or easily retrived by shell script. But on windows build, i have to install python manually from .msi before running CMake. Is there any good workaround using cmake scripts?
PS All other external dependencies are downloaded from dedicated FTP server.
Python doesn't really have to be installed to function properly. For my own CMake based projects on Windows, I just use a .zip file containing the entire python tree. All you need to do is extract it to a temporary directory, add it to your path, and set your PYTHONHOME/PYTHONPATH environment variables. Once that's done, you have a fully operational Python interpreter at your disposal. About the only 'gotcha' on Windows is to make sure you remember to copy the Python DLL out of C:\Windows\system32 into the top-level Python directory prior to creating the .zip.