Building Ada sources for multiple projects, with installing the libraries and sources after each project build, works fine for gnatmake and a gnat.adc containing
pragma Wide_Character_Encoding(UTF8);
but not for gprbuild, no matter what I try.
package Compiler is
for Default_Switches ("ada") use ("-gnatW8");
end Compiler;
or
package Builder is
for Global_Configuration_Pragmas use "gnat.adc";
--The same I used with gnatmake just fine
end Builder;
Am I missing something? When I run a program with projects build with gprbuild I get bracket encoding output instead of the Unicode characters.
The build even has -gnatW8 on the command line. In fact, the command line args during each build are identical, but they produce notably different output when a program is run.
Progress:
Upon noticing the generated files for stand-alone libraries were not built with -gnatW8, I removed all interface declarations for the gpr files, and build standard shared libraries. Programs built with these respect Unicode, and do not output bracket encoded text. So now, the question is why stand-alone libraries aren't obeying the character encoding pragma or flag.
Related
I'm having troubles distributing a GtkAda application on Windows. I made an executable (with Windows native compiler) and tried using it on another Windows computer. However, I get errors about dlls missing.
I tried distributing with my .exe three folders.
bin including the dlls installed by GtkAda,
etc including fonts, gtk-3.0 and pango,
lib including gtk-3.0 with dlls too.
This is what I read from the GtkAda documentation
I think I maybe forgot to specify something in the project file
Here my GPS project file
with "C:\GNAT\GTK\lib\gnat\gtkada";
project Logfilter is
for Source_Dirs use ("src");
for Object_Dir use "obj";
for Exec_Dir use "exec";
for Main use ("log_filter_main.adb");
package Builder is
for Executable ("main.adb") use "Logs_Filter";
end Builder;
package Compiler is
for Switches ("ada") use ("-Wl,--subsystem,windows");
end Compiler;
end Logfilter;
I'm using a glade (gtk 3.14) file and GtkAda 2019.
Thank you.
Where did you put the main executable (log_filter_main.exe)? What libraries are missing?
When I create a directory structure using the batch program below (change the variables GTKADA_INSTALL_DIR and TARGET_DIR to match your situation), and then copy my executable (a simple GtkAda program) into %TARGET_DIR%\bin, then this executable runs just fine. It's important that the application resides in the bin folder such that the correct GTK runtime libraries will be found during startup.
create_standalone.bat
SET GTKADA_INSTALL_DIR=C:\GNAT\2019\GtkAda
SET TARGET_DIR=C:\Test
xcopy /s /i %GTKADA_INSTALL_DIR%\bin\*.dll %TARGET_DIR%\bin\
xcopy /s /i %GTKADA_INSTALL_DIR%\etc\*.* %TARGET_DIR%\etc\
xcopy /s /i %GTKADA_INSTALL_DIR%\lib\gtk-3.0\*.* %TARGET_DIR%\lib\gtk-3.0\
REM Copy your GtkAda application (.exe and other dependencies if applicable)
REM to %TARGET_DIR%\bin\
Regarding the project file: first, it's not completely clear why the Builder package is needed, but I might lack some project specific knowledge/requirements here. Second, if you want to get rid of the console window popping up when starting the GUI application, then you might want to use
package Linker is
for Switches ("ada") use ("-mwindows");
end Linker;
instead of
package Compiler is
for Switches ("ada") use ("-Wl,--subsystem,windows");
end Compiler;
Note:
Small additional note beyond the scope of the question (you may already have thought of it): please do not forget to quit the GTK main application when you close the main window. Define (for example):
procedure Destroy_Event_Callback
(Widget : access Gtk.Widget.Gtk_Widget_Record'Class)
is
begin
Gtk.Main.Main_Quit;
end Destroy_Event_Callback;
and then register it as a callback when the main window is initialized:
Main_Window.On_Destroy (Destroy_Event_Callback'Access);
If the Gtk.Main.Main_Quit call is omitted, then the program (process) will keep running after you close the main window (at least when you use the -mwindows linker option).
My code is:
with Ada.Text_IO; use Ada.Text_IO;
procedure Hello is
begin
Put_Line ("Hello, world!");
end Hello;
GNAT makes a .o and .ali.
I type
gcc hello.o -o hello
GCC complains:
/usr/lib/gcc/i686-linux-gnu/6/../../../i386-linux-gnu/crt1.o: In function `_start':
(.text+0x18): undefined reference to `main'
hello.o: In function `_ada_hello':
hello.adb:(.text+0x26): undefined reference to `ada__text_io__put_line__2'
collect2: error: ld returned 1 exit status
You shouldn't try to compile Ada programs by hand with the gcc command. There are two sensible alternatives depending on your preferences:
Use the gnatmake command as Brian suggests in his comment. This works well as long as all the relevant source files are stored in the same directory.
Create a project file and use gprbuild. Projects can handle source files distributed in multiple directories, include other projects, contain compiler and linker flags, etc.
On the "Hello_World" level, gnatmake works okay, but you should be aware that gnatmake doesn't behave like a real Ada compiler, unless you pass it some specific flags. I've managed this with an alias in my shell, but in reality it is yet another argument in favour of using gprbuild even for tiny projects, as you can put the flags which make GCC behave like a real Ada compiler in the project files, and not worry more about it.
project Hello_World is
for Source_Dirs use ("src");
for Object_Dir use "obj";
for Exec_Dir use "bin";
for Main use ("hello.adb");
package Builder is
for Default_Switches ("Ada")
use ("-m");
end Builder;
package Compiler is
for Default_Switches ("Ada")
use ("-fstack-check", -- Generate stack checking code (part of Ada)
"-gnata", -- Enable assertions (part of Ada)
"-gnato13", -- Overflow checking (part of Ada)
"-gnatf", -- Full, verbose error messages
"-gnatwa", -- All optional warnings
"-gnatVa", -- All validity checks
"-gnaty3abcdefhiklmnoOprstux", -- Style checks
"-gnatwe", -- Treat warnings as errors
"-gnat2012", -- Use Ada 2012
"-Wall", -- All GCC warnings
"-O2"); -- Optimise (level 2/3)
end Compiler;
end Hello_World;
If you use GNAT Programming Studio (GPS) as your IDE, you may want to remove the -gnatf flag, as I have experienced that can prevent GPS from parsing the error messages from the compiler.
I'm trying to develop an R package that will include some previously compiled executable programs and their supporting libraries. (I know this is bad form, but it is for internal use).
My question: Does the special exec and tools directories have any special functionality within R?
The documentation seems to be sparse. Here is what I've figured out so far:
From here
files contained in exec are marked as executable on install
subdirectories in exec are ignored
exec is rarely used (my survey of CRAN says tools is just as rarely used)
tools is around for configuration purposes?
Do these directories offer any that I couldn't get from creating an inst/programs directory?
[R-exts] has this to say:
Subdirectory exec could contain additional executable scripts the
package needs, typically scripts for interpreters such as the shell,
Perl, or Tcl. This mechanism is currently used only by a very few
packages. NB: only files (and not directories) under exec are
installed (and those with names starting with a dot are ignored), and
they are all marked as executable (mode 755, moderated by ‘umask’) on
POSIX platforms. Note too that this is not suitable for executable
programs since some platforms (including Windows) support multiple
architectures using the same installed package directory.
It's quite possible the last note won't apply to you if it's only for internal use.
Nevertheless, I'd suggest avoiding abusing any existing convention that might not apply precisely to your situation, and instead use inst/tools or inst/bin.
As far as I can tell, here is the functionality offered by the exec and tools directories.
exec
From R-exts by way of hadley:
Subdirectory exec could contain additional executable scripts the package needs, typically scripts for interpreters such as the shell, Perl, or Tcl. This mechanism is currently used only by a very few packages. NB: only files (and not directories) under exec are installed (and those with names starting with a dot are ignored), and they are all marked as executable (mode 755, moderated by ‘umask’) on POSIX platforms. Note too that this is not suitable for executable programs since some platforms (including Windows) support multiple architectures using the same installed package directory.
exec features I have figured out
On POSIX platforms (*nix, os x), the files within exec will be marked as executable.
No subdirectories of exec are included in the package, only files in exec root
(note, it could contain binary executables, but there is no architecture/platform handling
tools
From R-exts:
Subdirectory tools is the preferred place for auxiliary files needed during configuration, and also for sources need to re-create scripts (e.g. M4 files for autoconf).
tools features I have figured out
tools is to hold files used at package compile time
All files contained are copied recursively into the source *.tar.gz package (including subdirs)
tools is not included in the final, compiled form of the package. All contents are dropped
Good day, i build my Qt project with Cmake build system on windows platform, but if i add line in cmake file: add_definitions("-DUNICODE -D_UNICODE") definition of UNICODE not working(MINGW), this work properly only if i build my project with MSVC compiler. After some times i found workaround How do I define a variable when I call CMake, so that qtcreator knows it is defined?, this solution work but if i use native WINAPI functions such as CreateFile i get the compile error, because compiler chose CreateFileA but i use w_char and i would like to use CreateFileW, this is because the definition of macro UNICODE appears before than i include my confugure file.How can i define UNICODE macro in cmakefile?
Have you tried (note the lack of quotes):
add_definitions(-DUNICODE -D_UNICODE)
I am using Qt in a project and am now trying to include another project that uses boost.
I have added no_keywords to my config in the qt project file to avoid collision between the signal and slots functionality that is present in boost and Qt. But now I get a compilation error which seems to stem from double definition of a function called "check". Is there some way to avoid this?
An example is has_postfix_operator.hpp (line 141):
static ::boost::type_traits::yes_type check(has_operator); // this version is preferred when operator exists
Apparently there is a "check" defined in Qt.
I'm using Qt4.7 and boost 1.48. Running MacOSX 10.6.8
You should also look at /usr/include/AssertMacros.h, which defines a macro named "check" - that could be the cause of your problem.
To check this, add -d __ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORES=0 to your compiler flags.
If that works, that was your problem.
Here's a comment from that file:
Prior to Mac OS X 10.6 the macro names used in this file conflicted
with some user code, including libraries in boost and the proposed C++
standards efforts, and there was no way for a client of this header to
resolve this conflict. Because of this, most of the macros have been
changed so that they are prefixed with
__ and contain at least one capital letter, which should alleviate the current and future conflicts. However, to allow current sources to
continue to compile, compatibility macros are defined at the end with
the old names. A tops script at the end of this file will convert
all of the old macro names used in a directory to the new names.
Clients are recommended to migrate over to these new macros as they
update their sources because a future release of Mac OS X will remove
the old macro definitions ( without the double-underscore prefix ).
Clients who want to compile without the old macro definitions can
define the macro
__ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORES to 0 before this file is included.