I'm trying to use GNAT 95 to compile a program on my computer running CENTOS 7 64-bit with the GNAT-GPL 2015 bundle. I get a compiler message that looks like this:
gprbuild: encapsulated library projects not supported on this platform
My GPR file looks like this:
with "bc.gpr"; -- Pull in the booch95 components since ada95 doesnt have collections
with "mylibrary.gpr"; -- one of my library projects
library project Registry is
for Source_Dirs use ("src/**");
for Object_Dir use "bin";
for Library_Name use "registry";
for Library_Standalone use "encapsulated";
for Library_ALI_Dir use "lib/registry";
for Library_Dir use "plugins";
for Library_Kind use "dynamic";
for Library_Interfaces use ("...");
package Compiler is
for Default_Switches ("Ada") use ("-g", "-gnat95");
end Compiler;
package Linker is
for Linker_Options use ("-ldl", "-lgcov");
end Linker;
end project;
The Booch Components library is a static library project. Removing the encapsulated causes Ada to throw another error about trying to mix static and dynamic libraries:
shared library project "registry" cannot import static library project "bc"
Any Idea what might be causing the Ada compiler to crash?
Unless you’re using a very old version of the BCs, you can build as a shared or dynamic library by setting the scenario variable LIBRARY_TYPE to relocatable; either by setting as an environment variable, or
gprbuild -XLIBRARY_TYPE=relocatable ...
or with GPS. I’m not a GPS user, but having investigated it seems (with GPS GPL 2014) you select Scenario in the tabs on the left hand side, which should show the scenario variables in your project and the projects it depends on (bc in your case). Select the one you want to change and click the pen icon, you get a dialog box to update it.
Related
Excuse the vague title.
I'm trying to build a package to help me use third-party cloud storage APIs (Firebase Storage for example), adding Combine support, etc. This package does the same thing with CloudKit. Everything compiles fine, but when I import the package module into a separate project of mine, the module is apparently missing some public symbols...
Specifically, the ones wrapped inside of an #if canImport(FirebaseStorage) condition. Since Firebase doesn't support SwiftPM yet, this part of the package behaves as expected in the package project itself; it simply skips compiling that whole bit. I figured that a client project that can import this module would compile it fine.
Aside: What I'm trying to do looks something like optional dependencies. I don't want to have to import Firebase to use this package's other features. I have considered splitting the package into separate sub-packages, each depending upon the particular third-party library I want to use. I might do that anyway. But the problem remains that Firebase doesn't yet support SwiftPM (although I hear they're close).
My issue appears similar to this one. My client project just doesn't seem to see the conditioned symbols, though it can import Firebase and FirebaseStorage just fine! I mean that the generated module header is missing them entirely, preventing my client project from compiling when I use them.
It seems to me that the compile condition never leaves the package's own scope of dependent targets. Is this the case? Or am I missing something obvious? I had always assumed that Swift Packages just import and compile the Swift source files into named modules, but now I think that is not so.
Is there a way to build code into a Swift Package that compiles only when the client can import a third-party module that does not yet support SwiftPM? Or does conditional compilation not work that way?
EDIT: Here is the Swift documentation on conditional compilation, for reference.
(Answer from experience in Apr 2020)
It looks like I'm just misunderstanding the compile order.
Importing my packaged module (let's call it CloudStorage) declares a dependency in the client project to that module. Before the client project can compile with its other dependencies, CloudStorage needs to compile without the main project's dependencies. Since CloudStorage doesn't know anything about those dependencies, canImport for those dependencies evaluates to false.
This may have changed in a later version of Swift. I've yet to try again.
canImport checks whether the module name provided can be imported. For swift packages, this evaluates to true if you have provided the module as a target dependency in the package manifest and all of its associated target dependency condition are satisfied.
The benefit of this is this allows you to write code in a platform agnostic way and let your package manifest take care of platform support.
Let's say I have Firebase as a dependency in my target:
.product(name: "Firebase", package: "firebase-ios-sdk", condition: .when(platforms: [.iOS, .macOS, .tvOS])),
I can write my code that depends on Firebase with canImport. Suppose in future firebase-sdk started supporting another platform, I can add the platform to my availability condition and start supporting that platform in my code as well.
But if you don't have the module listed as dependency, even if your client app can import the module, this condition will always evaluate to false. This is due to the sandbox nature of swift package build system and all your package targets are isolated so that consuming client's build settings doesn't affect your package target.
I have already set up build and debug environment for Object Pascal inside Visual Studio Code via FPC and GDB, but I just made build process work for programs containing only 1 .pas file via
"command": "fpc",
"args": [ "-g", "-Px86_64", "helloWorld.pas" ],
Now, I need to build quite big Delphi project group (something like solution?) and it contains main project file .groupproj.
Is there a way to build the .groupproj via FPC somehow?
Or at least some workaround like conversion to .lpi and then build via FPC?
Or at least call Delphi compiler/builder from VS Code and build the whole project group via it? (but I don't like this option, because I prefer to not use Delphi)
To get some facts straight for other people that might stumble on this:
FPC supports Delphi source files (.lpr/.dpr, .pp/.pas and .inc). Not Delphi meta information (.dproj/.dof/.bpg/.cfg/.groupproj) which is Delphi version dependent anyway.
Lazarus conversion tool also converts .dfms. Basically it is a .dfm cleaner and Uses clause enhancer, just like some conversion tools between Delphi versions. It by default however also does substitutions that change Delphi code (that works in FPC's Delphi (-Sd) mode) into the objfpc dialect (-S2 mode) preferred by Lazarus . Always make a backup before trying, and check the configuration of the conversion tool thoroughly.
FPC and Delphi commandline parameters are different.
FPC does not support Lazarus metadata formats like .lpi. The Lazarus utility Lazbuild however does support building Lazarus projects from the commandline.
But luckily the basics are the same
a main program or library file files)
a set of unit (.pas files) and include directories (.inc files). FPC differentiates between the two, delphi doesn't.
autocreated forms must be added to the project.
any additional commandline switches like defines to set, range checking optimization options.
So in worst case, examine the Delphi projects (either in IDE or texteditor) for directories and switches and create either a manual buildscript or a lazarus (.lpi) project.
However it is vital to keep in mind that the default FPC mode is NOT Delphi mode, so always when executing FPC make sure you manually enable Delphi mode (-Sd)
Group project support within Lazarus is very new (as in months), and afaik not even in stable versions yet. Though if you create a bunch of .lpis, a batch file/shellscript with a sequence of lazbuild commands on .lpis might do it.
P.s. throw the VSCode under the bus and use Lazarus.
When developing a library in Rust (+ Cargo), how do I achieve the fast recompile/test cycle?
When developing an app, it's easy, I:
Make changes in the code
Switch to the terminal and run cargo run
See the compiler feedback
But now I want to extract parts of my app as a library and publish it on GitHub.
I would like to continue developing my app, but now with this library as a dependency. I'm going to develop both the library and the app in parallel.
How do I get same quick feedback now?
Both the library and the app will be developed on the same machine, I would like to make changes to the library, update the app correspondingly and see the compiler feedback.
I'm guessing I could use my library as a dependency in Cargo.toml and run cargo update each time I want to update my app's dependencies, but this will be somewhat slow because it will have to download the code from github each time and recompile all dependencies.
You can use this somewhat undocumented feature of cargo. Add the following line to ~/.cargo/config file (or /path/to/your/binary/project/.cargo/config to limit the effect to your binary project):
paths = ["/path/to/your/library"]
From now on every cargo package (or those under /path/to/your/binary/project root) which depends on your library will use /path/to/your/library as the source code for it regardless of what is specified in this package manifest, so you can keep Git repo URL in your program manifest. Hopefully this feature will be documented in future.
Update
This is now documented in the Cargo guide.
I have custom package, where the sourcecode is directly in the package directory.
At the moment buildroot copies the sourcode to the builddirectory.
Is it possible to avoid this unnecessary overhead? The Makefile supports srcdir != builddir.
in < 2011 buildroot it was possible to specify the SRCDIR and nothing was rsynced.
This is unfortunately not supported right now. We are working on supporting out-of-tree build on a per-package basis in order to solve this issue. A first prototype has been sent to the list some time ago, but needs more work.
so what I'm trying to do is utilize a simple Qt application IN eclipse without using the eclipse QT plugin by linking the required libraries through the GCC C++ Linker. However, I have been unable to locate the exact name of the library to use, or which libraries will be necessary. I've located the path of the Qt library my application seems to be accessing, but I continue to get an error when building that just says "-lqt" doesn't exist/can't find, etc.
The reason I'm doing this is because I'm building a simple game in OGRE for a project at the uni and wanted to use a Qt application for the GUI. Well, I didn't necessarily want too, but our professor wishes us to do so. Please don't suggest that I simply embed an Ogre widgit into my Qt application as this isn't an opti
Any ideas?
Thanks <3
Well, if you are using CMake then it should take care of everything provided that you instructed it to do so. phb provided a link to even better instructions.
First step is to instruct the CMake that we need Qt for our project. This is done with (you can specify individual parts that are needed as well):
find_package(Qt4 REQUIRED)
If Qt is not found in the typical locations (e.g. QTDIR is not set) - cmake will fail.
You also have to instruct CMake to use Qt include paths and set certain compiler definitions:
include(${QT_USE_FILE})
add_definitions(${QT_DEFINITIONS})
Finally, for each target you need to tell that you'd like to link with Qt libraries:
target_link_libraries(foo ${QT_LIBRARIES})
You might also want to process your headers and will have to process the user interface files with moc. For the details please refer to the provided links.
In addition to provided links you can have a look at the comments at the top of FindQt4.cmake file.