gprinstall prefix in project file - ada

The gprinstall program part of the GNAT tool-set seems to ignore the prefix attribute in the project file. It does use the --prefix when specified on the command line. Is there a way to force it to use the prefix in the project file?

In your project file, you simply add the package Install, where you declare which prefix you want to use:
package Install is
for Prefix use "/tmp/installed";
end Install;
If you declare a relative path, it will be prefixed with either the default prefix or the one passed on the command line.
See the manual for further details.

Related

How to specify indent in jq config file?

Instead of always giving the --indent n flag on the command line, I would like to specify this in a config file (or library or module file – I'm not sure what the correct terminology is).
I tried putting various things in ~/.jq, such as indent: 4 or --indent 4, but they always gave me a compile error when I invoked jq. I looked at the manual but couldn't see any information on how to do this, nor find anything in the issues on GitHub.
Is it possible?
The ~/.jq file contains jq code such as function definitions. It's not a config file in the classical sense.
Most shells support aliases and you could set one yourself, e.g. in ~/.profile or ~/.bashrc/~/.bash_aliases with:
alias jq='jq --indent 4'
When invoked in an interactive shell, the alias will be resolved to the command including the option. Note however that aliases are ignored in shell scripts (i.e. non-interactive mode) by default.

CMake - Copy DLLs to the runtime output directory

I am trying to create a simple CMake that retrieves the DLLs of Qt and copy it in the directory in which cmake creates my executable.
It works great using g++ or clang, but MSVC (Visual Studio 2017) creates a Debug or Release directory.
I can't find a way to retrieve the path to the real directory in which the executable is written (${CMAKE_CURRENT_BINARY_DIR} returns the directory parent of Release or Debug).
I've seen people using the target property RUNTIME_OUTPUT_DIRECTORY but it is empty when I use it.
Any idea how I can do this ? I do not want to change the output directory, I just want to know its path (so I do not want to change the value of RUNTIME_OUTPUT_DIRECTORY)
Thanks!
In Visual Studio, during configuration step (when CMakeLists.txt files are processed) build type is not set, so no build-type-dependent variable or property is usable directly. Instead, generator-expressions should be used.
E.g., output directory for executable or library target can be extracted with $<TARGET_FILE_DIR:tgt> generator expression. It will return full directory, with "Release/" or "Debug/" already appended.
Note, that generator expressions can be used only when their usage is explicitly allowed in documentation. E.g., they cannot be used in message() command.
Alternatively, you may explicitely set variable CMAKE_RUNTIME_OUTPUT_DIRECTORY, so for every build type will just append appropriate subdirectory to it. But for extracting this subdirectory, you should again resort to generator expressions: $<CONFIG>.
Technically, it is possible to set the same output directory for any build type. But this is not recommended, because a file from one build type will be overwritten by the file from another build type.
Example for Visual Studio 2022 and CMake.
Place this at the end of CMakeLists.txt:
if (WIN32)
add_custom_command(
TARGET qcpp POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy_if_different "${PROJECT_SOURCE_DIR}/include/external/c.dll" "${CMAKE_BINARY_DIR}"
COMMAND_EXPAND_LISTS
)
endif()
See list of CMake variables.
Note the "qcpp" in the preceding command. This is the project name and should match this line at the start:
project ("qcpp")
Appendix A - Testing
To verify, if you generate a Visual Studio Project using mkdir x && cd x && cmake .., you can see that CMake has added a post-build step to the solution config:
As of CMake 3.21+, the $<TARGET_RUNTIME_DLLS:tgt> generator expression can help copy dependent DLLs to the build tree. Quoting the documentation:
List of DLLs that the target depends on at runtime. This is determined by the locations of all the SHARED and MODULE targets in the target's transitive dependencies. Using this generator expression on targets other than executables, SHARED libraries, and MODULE libraries is an error. On non-DLL platforms, it evaluates to an empty string.
This generator expression can be used to copy all of the DLLs that a target depends on into its output directory in a POST_BUILD custom command.
Docs link: https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html#genex:TARGET_RUNTIME_DLLS
An example of how to use this (adapted from the docs) follows:
find_package(foo REQUIRED)
add_executable(main main.cpp)
target_link_libraries(main PRIVATE foo::foo)
if (WIN32)
add_custom_command(
TARGET main POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy_if_different
$<TARGET_RUNTIME_DLLS:main> $<TARGET_FILE_DIR:main>
COMMAND_EXPAND_LISTS
)
endif ()
The if (WIN32) check ensures that $<TARGET_RUNTIME_DLLS:main> won't be empty, which would cause the command to fail (rather than do nothing). COMMAND_EXPAND_LISTS makes sure that the semicolon-delimited list returned by $<TARGET_RUNTIME_DLLS:main> will be split into multiple arguments, rather than passed as a single argument with (escaped) semicolons in it.
Note also that UNKNOWN libraries will be ignored by this generator expression. These are common when using the built-in Find modules, rather than using a library's first-party CMake config-mode package. In these cases, you will have to manually inspect the module variables to find the library paths and add custom commands for each one yourself.
For Qt specifically, I would expect the newer CMake integration in Qt6 to "just work", though I haven't tested it. It might also work in Qt5, but again I haven't tested it.

Not able to run Scriptcs scripts in Atom using atom-runner

I am trying to setup Atom editor on Mac for use with ScriptCs scripts. So I followed the guide to do that.
execvp(): No such file or directory
I have scriptcs as an alias in my .profile. Running scriptcs test.csx in the terminal used to launch Atom, works. It seems like Atom is not aware of the profile alias.
What should I do to make this work in Atom ?
Atom-runner is using a call to exec to invoke scriptcs directly, rather than going through a shell, so it won't be able to pick up anything that you have in your dotfiles. You'll either need to:
Put scriptcs on your $PATH normally, rather than using an alias. Sometimes you can do this with symlinks or changing its installation directory, for example.
Specify the absolute path to your scriptcs executable in your Atom config, instead:
'runner':
'extensions':
'csx': '/full/path/to/where/you/installed/scriptcs'

How can the install path be set for a qt project

I'm looking for the equivalent to ./configure --prefix= for qmake. Basically, I want to override the default install/deployment directory. How is this specified with command line qmake? I also use QtCreator to build a lot of my gui projects, and I'd like to know how to do the same thing while building inside of QtCreator. Is there a variable that I can manipulate in the .pro files to do this, or do I change my project settings?
Thanks!
For me, it seems that qmake PREFIX=/usr/local doesn't work
(try with the source of qtcreator)
So the solution is to use qmake normally, but then, you do
make
INSTALL_ROOT=/usr/local make install
I've found the solution to this, and it is just as easy as specifying the --prefix option to configure.
For qmake on the command line, you simpy add a PREFIX= parameter:
qmake PREFIX=/usr/local
There are two ways to do this in QtCreator. First, you could change your .pro file to include an explicit PREFIX variable definition. However, this is not recommended, as the prefix is a preference specific to each user, and it is preferable to keep the distributed project files generic. A better way to do this, is in your own project settings. Simply go to the build configuration that you are using, expand the qmake settings, and add PREFIX= to the additional arguments.

Location of configuration in unix program

I want to write a unix/linux program, that will use a configuration file.
My problem is, where should I put the location of the file?
I could "hardcode" the location (like /etc) into the program itself.
However, I would like it, if the user without privileges could install it (through make) somewhere else, like ~.
Should the makefile edit the source code? Or is it usually done in a different way?
Create some defaults:
/etc/appname
~/.appname
Then if you want to allow these to be overridden have your application inspect an environment variable. e.g.
$app_userconfig
$app_config
Which would contain an override path/filename.
Lastly add a command line option that allows a config to be specified at runtime, e.g.
-c | --config {filename}
It is common to use a series of places to get the location:
Supplied by the user as a command line argument (i.e. ./program -C path/to/config/file.cfg).
From an environment variable (char *path_to_config = getenv("PROGRAMCONFIG");).
Possibly look for a user specific or local version (stat("./program.cfg") or build up a strig to specify either "$HOME/.program/config.cfg" or "$HOME/.program.cfg" and stat that).
Hardcoded as a backup (stat("/etc/program/config.cfg",...)).
keeping a global config file under /etc/prgname is a standard. Also allowing a .local config file for individual users that will override the global settings would allow each user to personalize the program to their preference.
As skaffman says, the canonical locations for things like config files are specified in FHS. There appears to be a convention that a program will read a config file from the directory from which it is run as an alternative to the one in the hard-coded location. You may wish to consider adding a command-line switch that allows a user to specify an alternative config file location, as well.
The makefile shouldn't modify the source directly, but it can pass a folder path/name to the compiler through the -D option. One way to handle it would be to #define something like DEFAULT_PATH to be the default installation path. If the user wants to define a path, the makefile would add -DUSER_PATH=whatever to the compiler options. You would write your code to use USER_PATH if it exists, and DEFAULT_PATH otherwise.

Resources