Error when compiling with the "GPR" dependency - ada

I see the following error when compiling an Ada project with GNAT Studio, using the project dependency "gpr.gpr".
Error:
error
Here is my project source code:
with "gpr.gpr";
project Default is
for Soure_Dirs use ("src");
for Object_Dir use "obj";
for Main use ("main.adb")
end Default;
There is a line within gpr.gpr that is causing the error:
error-on-line
If I were to reference another dependency, such as "aws.gpr", everything works fine. However, "gpr.gpr" and any project that references it does not compile.
Output to: gprbuild -vP2 -P default.gpr
Process tree, phase 1
Value_Of (library_type) is default "static"
Value_Of (xmlada_build) is default "static"
Value_Of (library_type) is default "static"
Value_Of (xmlada_build) is default "static"
Value_Of (library_type) is default "static"
Value_Of (xmlada_build) is default "static"
Value_Of (library_type) is default "static"
Value_Of (xmlada_build) is default "static"
Value_Of (library_type) is default "static"
Value_Of (xmlada_build) is default "static"
Value_Of (library_type) is default "static"
Value_Of (gpr_build) is "C:\GNAT\2020\bin"
ERROR: value %% is illegal for typed string %%
Done Process tree, phase 1, Success=FALSE
gpr.gpr:11:04: value "C:\GNAT\2020\bin" is illegal for typed string "build"
gprbuild: "default.gpr" processing failed

Based on the comments to the original question, it appeared that an environment variable named GPR_BUILD was set while a scenario variable named GPR_BUILD is used by the project gpr.gpr. The error could be reproduced given the project file source and by executing on the Windows command line
> set GPR_BUILD=C:\GNAT\2020\bin
and then
> gprbuild -P default.gpr
gpr.gpr:11:04: value "C:\GNAT\2020\bin" is illegal for typed string "build"
gprbuild: "default.gpr" processing failed
For more info on scenario variables, see the GPRbuild user's guide, section 2.4.

Related

How to handle the "wildcard" * asterisk on a Windows Command

Using
Windows
Local by Flywheel
Composer (task runner)
Working on a Child Theme to a Custom Made "Core" theme.
I'm running composer install on the root of my WP directory to install dependencies on a parent and child theme.
Problem is when the installations are running it errors out when it gets to the src/*.js. I asked the team that set up the page and they told me that it was a problem with how Windows handles wildcard characters, which I understand it as the asterisk* and that they solved it in the pass by getting their employee a Mac. Since these dependencies are not going through, there's files that aren't loading on the website.
Getting a Mac, to solve this issue, is not on the table, so I'm looking to figure out what other options do I have to run this command successfully on a windows?
I tried going directly to the src/ folder and running npx wp-scripts start src on each .js file individually, and it gave a "successful build" message each time, but that didn't fix the issues on the page.
> wp-scripts build src/*.js
assets by status 95 bytes [cached] 2 assets
Entrypoint * = *.js *.asset.php
ERROR in *
Module not found: Error: Can't resolve './src/*.js' in 'C:\Users\UserName\Local Sites\localSiteName\app\public\wp-content\themes\parentThemeName'
resolve './src/*.js' in 'C:\Users\UserName\Local Sites\localSiteName\app\public\wp-content\themes\parentThemeName'
using description file: C:\Users\UserName\Local Sites\localSiteName\app\public\wp-content\themes\parentThemeName\package.json (relative path: .)
Field 'browser' doesn't contain a valid alias configuration
using description file: C:\Users\UserName\Local Sites\localSiteName\app\public\wp-content\themes\parentThemeName\package.json (relative path: ./src/*.js)
no extension
Field 'browser' doesn't contain a valid alias configuration
C:\Users\UserName\Local Sites\localSiteName\app\public\wp-content\themes\parentThemeName\src\*.js doesn't exist
.js
Field 'browser' doesn't contain a valid alias configuration
C:\Users\UserName\Local Sites\localSiteName\app\public\wp-content\themes\parentThemeName\src\*.js.js doesn't exist
.json
Field 'browser' doesn't contain a valid alias configuration
C:\Users\UserName\Local Sites\localSiteName\app\public\wp-content\themes\parentThemeName\src\*.js.json doesn't exist
.wasm
Field 'browser' doesn't contain a valid alias configuration
C:\Users\UserName\Local Sites\localSiteName\app\public\wp-content\themes\parentThemeName\src\*.js.wasm doesn't exist
as directory
C:\Users\UserName\Local Sites\localSiteName\app\public\wp-content\themes\parentThemeName\src\*.js doesn't exist
webpack 5.64.1 compiled with 1 error in 149 ms
Script cd wp-content/themes/parentThemeName && npm install && npm run build && composer install --no-interaction --ansi --ignore-platform-reqs handling the install-core-deps event returned with error code 1
Script composer install-core-deps && composer install-child-deps handling the post-install-cmd event returned with error code 1
Thanks for any and all help.
Cheers!

Tap-i18n is not enabled in the project level, check tap-i18n README

Trying to implement TAP-i18n in a Meteor-1.7 app. I have installed it, and have followed the setup as detailed on the page. The i18n JSON files are in startup/both/i18n/en and fr directory thus:
{
"headers" : {
"appheader" : "OLTega",
"home" : "Home"
}
}
Template implementation:
<template name="header">
{{_ 'headers.home'}}
</template>
I kept on getting this error:
Exception in defer callback: Error: No such function: _
at blaze.js?hash=a1ff2d6d5ecd59ee11e2ba260b8650a9d1140f59:3214
at Spacebars.call (spacebars.js?hash=547cf8e466d1d52603d19bd5f48fb5df184fd237:172)
at Spacebars.mustacheImpl (spacebars.js?hash=547cf8e466d1d52603d19bd5f48fb5df184fd237:106)
at Object.Spacebars.mustache (spacebars.js?hash=547cf8e466d1d52603d19bd5f48fb5df184fd237:110)
at Blaze.View._render (app.js?hash=af2511f3e4a636f030d9ecbfdc553bf9ad12b1a6:400)
at Blaze.View.doRender (blaze.js?hash=a1ff2d6d5ecd59ee11e2ba260b8650a9d1140f59:2086)
at blaze.js?hash=a1ff2d6d5ecd59ee11e2ba260b8650a9d1140f59:1934
at Function.Template._withTemplateInstanceFunc (blaze.js?hash=a1ff2d6d5ecd59ee11e2ba260b8650a9d1140f59:3744)
at blaze.js?hash=a1ff2d6d5ecd59ee11e2ba260b8650a9d1140f59:1932
at Object.Blaze._withCurrentView (blaze.js?hash=a1ff2d6d5ecd59ee11e2ba260b8650a9d1140f59:2271)
detectlang.js:16 tap-i18n is not enabled in the project level, check tap-i18n README
I have checked the README.md and donot understand this statement:
tap-i18n can be used to internationalize projects and packages, but its behavior is determined by whether or not it's installed on the project level. We call these two work modes: enabled and disabled.
It is installed, and shows in the packages file. What am I to do to get it working?

Flowtype declaration in interface file precedence

Trying to Flow type check a node project. I use a timer and unref it so not to keep the node process running when shutting down.
unref isn't present in timers used in the browser, so to circumvent this I have added a declaration before...
declare var setInterval : any;
setInterval(function(){ ...
... and type checking succeeds. However if I move this declaration to an interface file (similar to the example Checking third-party code example) it doesn't appear to be used and I get the following error:
call of method unref
Property not found in
... core.js:70:1,87:1: Number
Does the definition in core.js take precedence?
When this question was posed, the builtin lib files did take precedence over any user lib files and there was no way to override them.
Starting with Flow v0.19.0 (released on Dec. 1st, 2015), you can now override the built in libraries. The the order of precedence from highest to lowest is as follows:
Lib files specified from the commandline with --lib
Lib files specified in the [libs] section of the .flowconfig
The builtin libraries

Command 'generate' not found, compiling with rebar

I am following this blog:
http://maplekeycompany.blogspot.se/2012/03/very-basic-cowboy-setup.html
In short, I am trying to compile an application with rebar just as the person in the blog.
Everything goes smoothly until I want to run the command:
./rebar get-deps compile generate
This then give me the following errors and warnings,
> User#user-:~/simple_server/rebar$ ./rebar get-deps compile generate
> ==> rebar (get-deps)
> ==> rebar (compile) Compiled src/simple_server.erl Compiled src/simple_server_http.erl src/simple_server_http_static.erl:5:
> Warning: behaviour cowboy_http_handler undefined Compiled
> src/simple_server_http_static.erl
> src/simple_server_http_catchall.erl:2: Warning: behaviour
> cowboy_http_handler undefined Compiled
> src/simple_server_http_catchall.erl WARN: 'generate' command does not
> apply to directory /home/harri/simple_server/rebar Command 'generate'
> not understood or not applicable
I have found a similar post with the same error:
Command 'generate' not understood or not applicable
I think the problem is in the reltool.config but do not know how to proceed, I changed the path to the following: {lib_dirs, ["home/user/simple_server/rebar"]}
Is there a problem with the path? How can rebar get access to all the src files and also the necessary rebar file to compile and build the application?
You need to make sure your directory structure and its contents are arranged so that rebar knows how to build everything in your system and generate a release for it. Your directory structure should look like this:
project
|
-- rel
|
-- deps
|
-- apps
|
-- myapp
| |
| -- src
| -- priv
|
-- another_app
The rel directory holds all the information needed to generate a release, and the apps directory is where the applications that make up your project live. Application dependencies live in the deps directory. Each app such as myapp and another_app under the apps directory can have their own rebar.config files. While two or more such applications are possible here, normally you'd have just one and all others would be dependencies.
In the top-level project directory there's also a rebar.config file with contents that look like this:
{sub_dirs, ["rel", "apps/myapp", "apps/another_app"]}.
{lib_dirs, ["apps"]}.
If necessary, you can use rebar to generate your apps from application skeletons:
cd apps
mkdir myapp another_app
( cd myapp && rebar create-app appid=myapp )
( cd another_app && rebar create-app appid=another_app )
If an application has dependencies, you'll have to add a rebar.config to its directory and declare each dependency there. For example, if myapp depends on application foo version 1.2, create apps/myapp/rebar.config with these contents:
{deps,
[{foo, "1.*", {git, "git://github.com/user/foo.git", {tag, "foo-1.2"}}}]
}.
When you run rebar get-deps, rebar will populate the top-level deps directory to hold all dependencies, creating deps if necessary. The top-level rebar.config can also declare dependencies if necessary.
You also need to generate a node, necessary for your releases:
cd ../rel
rebar create-node nodeid=project
You then need to modify the reltool.config file generated by the previous step. You need to change
{lib_dirs, []},
to
{lib_dirs, ["../apps", "../deps"]},
and just after the line {incl_cond, derived}, add {mod_cond, derived}, so that releases contain only the applications needed for correct execution.
Next, wherever the atom 'project' appears, you need to replace it with the applications under the apps directory. For our example, we'd change this part:
{rel, "project", "1",
[
kernel,
stdlib,
sasl,
project
]},
to this:
{rel, "project", "1",
[
kernel,
stdlib,
sasl,
myapp,
another_app
]},
and change this part:
{app, project, [{mod_cond, app}, {incl_cond, include}]}
to this:
{app, myapp, [{mod_cond, app}, {incl_cond, include}]},
{app, another_app, [{mod_cond, app}, {incl_cond, include}]}
You might also need to add the line:
{app, hipe, [{incl_cond, exclude}]},
to exclude the hipe application since sometimes it causes errors during release generation or when trying to run the release. Try without it first, but add it if you see errors related to hipe when generating a release, or if attempts to run the generated release result in this sort of error:
{"init terminating in do_boot",{'cannot load',elf_format,get_files}}
you'll need to add it.
With all this in place you can now execute:
rebar get-deps compile generate
and you should be able to successfully generate the release. Note that running rebar generate at the top level rather than in the rel dir will result in a harmless warning like this, which you can ignore:
WARN: 'generate' command does not apply to directory /path/to/project
Finally, you can run the release. Here's how to run it with an interactive console:
$ ./rel/project/bin/project console
Exec: /path/to/project/rel/project/erts-6.2/bin/erlexec -boot /path/to/project/rel/project/releases/1/project -mode embedded -config /path/to/project/rel/project/releases/1/sys.config -args_file /path/to/project/rel/project/releases/1/vm.args -- console
Root: /path/to/project/rel/project
Erlang/OTP 17 [erts-6.2] [source] [64-bit] [smp:8:8] [async-threads:10] [kernel-poll:false]
Eshell V6.2 (abort with ^G)
(project#127.0.0.1)1>
or you could run ./rel/project/bin/project start to start it in the background. Run ./rel/project/bin/project with no arguments to see all available options.

ivy.xml based sbt publish

There are 2 questions,
I defined publishTo with a resolver "abc", which is not in the external ivysettings.xml. When I do the publish, sbt complains resolver "abc" is undefined.
I defined an artifact, which is a zipped package, to be published, and the corresponding settings are as follows,
val ZIP = Configurations.config("app")
val artifact = SettingKey[Artifact]("artifact")
val pack = TaskKey[File]("pack")
val settings = Seq(artifact := Artifact(name.value, "zip", "zip", Some("app"), List(ZIP), None)) ++ addArtifact(artifact, pack).settings
It works pretty well when dependencies are managed by sbt itself, but totally cannot work (meaning the local publish just ignores publish of this artifact) if they are managed by ivy. How can I get over these?
Seems like the custom artifact settings does not work only if they are imported with an auto plugin, is it a bug or am I missing something?
thanks to this post:
How can a default task be overridden from an AutoPlugin?
so the artifacts settings must be introduced after sbt's own plugins are imported, otherwise it'd be overwritten.

Resources