I want to have a structure like /project/functions /project/src. I would have a unit /project/functions/helloUnit.pas similar to:
unit helloUnit;
interface
implementation
uses classes;
procedure helloWorld(output);
begin
writeln('Hello, World');
end.
And a file /project/src/main.pas like:
uses helloUnit;
Begin
helloWorld;
End.
I've been trying to make it work but haven't found the way. I'm using fpc compiler on linux command line in case I'm not defining the path or something.
There are some things wrong with your example code, which it would be helpful to fix
before attempting to compile it from the command line.
Firstly, you need a project file for fpc to compile to produce your program. For this,
I created this file in the projects folder and named it hello.lpr:
program Hello;
uses
hellounit,
main;
begin
HelloWorld;
end.
Then correct Main.Pas as follows:
unit main;
interface
uses helloUnit;
procedure SayHello;
implementation
procedure SayHello;
Begin
helloWorld;
End;
End.
Note that procedure SayHello; has been added to the interface section and that End;
has been added to the end of the declaration of the procedure. The End. tells the
compiler that it has reached the end of the source code in the unit.
Next correct helloUnit as follows
unit helloUnit;
interface
procedure helloWorld;
implementation
uses classes;
procedure helloWorld;
begin
writeln('Hello, World');
end; {added}
end.
Now write a batch file CompileHello.Bat (assuming Windows) in the projects folder
containing
D:\Lazarus2\fpc\3.0.4\bin\i386-win32\fpc -Fufunctions;src hello.lpr
and then run it from a CMD prompt in the projects folder. The -Fu compiler switch tells fpc
where to find units which are not located in the same folder as the project
file. The paths after -Fu can be relative to the project folder. If you
have followed the steps above, it should comile successfully.
If you were using Lazarus, the companion IDE to fpc there would be at least two ways of doing what you asked.
With HelloUnit open in the IDE, use View | Add Editor File to Project from the IDE's menu to add HelloUnit to the project. This is probably the best way because it unambiguously identifies HelloUnit for the project.
Add the folder in which HelloUnit.Pas is located to the Project's Source Paths using Project | Options and, in the pop-up, under Compiler Options, add the folder to the Other Unit Files box on the RHS.
Related
I have a test file in my module's t/ directory that does a use on a TestUtils files which has some variables and routines:
use Test;
use TestUtils;
plan 4;
check_cmd_output('No arguments');
check_cmd_output('Successfully ingested', test_md_file);
check_cmd_output('Successfully ingested', test_md_file, 1);
check_cmd_output('Successfully ingested', vimwiki_arg_sim());
It works fine. However, Comma was complaining about TestUtils not being found "in the ecosystem" as well as throwing errors with identifiers from the TestUtils module that it was not loading:
I was able to stop Comma from complaining by:
Exporting the identifiers in the TestUtils file
Fully qualifying the identifiers in my test file with something like: TestUtils::check_cmd_output(...)
Adding TestUtils to the provides hash in the META6.json file.
I'm thinking there is probably a better way. I tried doing stuff like use lib 't' and use lib '.' but that did not help. Thanks.
Comma doesn't handle this situation perfectly; it understands (following the IntelliJ platform naming conventions):
Source roots, which are used as roots for resolving use statements within the project (anything not resolved is assumed to be from the module ecosystem)
Test roots, where test files are found (used for, for example, being able to run tests in an xt directory)
These are, however, mutually exclusive. If the TestUtils module were to be placed in a lib directory inside of t, then that lib directory could be marked as a source root, and the symbols should be resolved.
I am a little confused about how to structure a go web app and its tests. I have read the How to Write Go Code but still don't get it. For example, I have a go project called "beacon" with a beacon.go file at the root. Adding a trivial beacon_test.go file (copied verbatim from http://golang.org/pkg/net/http/httptest/#example_Server) causes this error:
$ go test
# github.com/jelder/beacon
./beacon_test.go:11: main redeclared in this block
previous declaration at ./beacon.go:216
FAIL github.com/jelder/beacon [build failed]
Sure enough, line 11 is func main(). If I instead change the package main line in my beacon_test.go to package hello, I get this error instead:
can't load package: package github.com/jelder/beacon: found packages main (beacon.go) and hello (beacon_test.go) in /Users/jacob/src/github.com/jelder/beacon
beacon_test.go has also a function called main() rename it to TestFirst (or any other name you like as long as it starts with Test, note the uppercase T is important). There is no need for that. Just run go test . from inside the package you are working on (the one containing the *.go files). Post the full files if you need more help.
This question is subsequent to my previous one: How to integrate such kind of source generator into CMake build chain?
Currently, the C source file is generated from XS in this way:
set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/${file_src_by_xs} PROPERTIES GENERATED 1)
add_custom_target(${file_src_by_xs}
COMMAND ${XSUBPP_EXECUTABLE} ${XSUBPP_EXTRA_OPTIONS} ${lang_args} ${typemap_args} ${file_xs} >${CMAKE_CURRENT_BINARY_DIR}/${file_src_by_xs}
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
DEPENDS ${file_xs} ${files_xsh} ${_XSUBPP_TYPEMAP_FILES}
COMMENT "generating source from XS file ${file_xs}"
)
The GENERATED property let cmake don't check the existence of this source file at configure time, and add_custom_target let the xsubpp always re-run at each compile. The reason for always rerun is because xsubpp will generate an incomplete source file even if it fails, so there are possibility that the whole compiling continues with an incomplete source file.
I found it is time consuming to always re-run source generator and recompile it. So I want to have it re-run only when dependent XS files are modified. However, if I do so, the incomplete generated source file must be deleted.
So my question is: is there any way to remove the generated file, only when the program exit abnormally at compile time?
Or more generic: is there any way to run a command depending on another command's exit status at compile time?
You can always write a wrapper script in your favorite language, e.g. Perl or Ruby, that runs xsubpp and deletes the output file if the command failed. That way you can be sure that if it exists, it is correct.
In addition, I would suggest that you use the OUTPUT keyword of add_custom_command to tell CMake that the file is a result of executing the command. (And, if you do that, you don't have to set the GENERATED property manually.)
Inspired by #Lindydancer's answer, I achieved the purpose by multiple COMMANDs in one target, and it don't need to write an external wrapper script.
set(source_file_ok ${source_file}.ok)
add_custom_command(
OUTPUT ${source_file} ${source_file_ok}
DEPENDS ${xs_file} ${xsh_files}
COMMAND rm -f ${source_file_ok}
COMMAND xsubpp ...... >${source_file}
COMMAND touch ${source_file_ok}
)
add_library(${xs_lib} ${source_file})
add_dependencies(${xs_lib} ${source_file} ${source_file_ok})
The custom target has 3 commands. The OK file only exists when xsubpp is success, and this file is added as a dependency of the library. When xsubpp is not success, the dependency on the OK file will force the custom command to be run again.
The only flaw is cross-platform: not all OS have touch and rm, so the name of these two commands should be decided according to OS type.
Please have a look at the following code
with text_io;
use text_io;
procedure hello is
begin
put_line("hello");
new_line(3);
end hello;
When I click "build all" in GPS IDE, I get this error
gnatmake -d -PC:\Users\yohan\firstprogram.gpr
firstprogram.gpr:1:06: literal string expected
firstprogram.gpr:2:01: "end" expected
gnatmake: "C:\Users\yohan\firstprogram.gpr" processing failed
[2013-04-03 13:29:58] process exited with status 4 (elapsed time: 00.47s)
I am very new to Ada, as you can see, this is my first program. Please help.
On the command line, gnatmake will happily compile a file which contains Ada code but has the extension .gpr. GPS knows "better" than that, and insists on treating myfirstprogram.gpr as a GNAT Project file, which of course it isn't.
You'll find life with GNAT much easier if you stick with its file naming conventions: .ads for a spec, .adb for a body, and the file name needs to be the unit name in lower case. In your case, the file should have been called hello.adb.
The simplest approach to creating a GNAT project file in GPS is to go to the Project menu and select New. The only places where you must enter data are on the "Naming the project" page (you might choose firstproject!) and the "Main files" page, where you'd click on the blue + to add hello.adb; you can Forward through the others.
After adding the main file, you can click Apply to install the new project file; now you can Build all and Run.
You may find the GPS tutorial helpful (Help menu, GPS ...)
The Story So Far
I've got a nice solution with a desktop application project, a few library projects, and a couple of development tools projects (also desktop applications). At the moment, my build server outputs all of the code into one OutputPath. So we end up with
drop-x.y.z\
Company.MainApplication.exe <-- main application
Company.MainApplicationCore.dll <-- libraries
Helper.exe <-- developer tools
Grapher.exe
Parser.exe
... <-- the rest of the output
But, we're growing up and people outside of our team want access to our tools. So I want to organize the output. I decided that what we would want is a different OutputPath per executable project
drop-x.y.z\
Company.MainApplication\
Company.MainApplication.exe <-- main application
Company.MainApplicationCore.dll <-- libraries
... <-- application specific output
Helper\
Helper.exe <-- developer tools
... <-- tool specific output
Grapher\
Grapher.exe
...
Parser\
Parser.exe
...
What I Did
I found this simple command. I like it because it retains all the Solution working-dir context that makes msbuild a pain.
msbuild /target:<ProjectName>
For example, from my solution root as a working directory, I would call
PS> msbuild /target:Helper /property:OutputPath="$pwd\out\Helper"
I'm testing this from PowerShell, so that $pwd resolves to the full path to my working directory, or the Solution root in this case. I get the output I desire.
However, when I run this command
PS> msbuild /target:Company.MainApplication /property:OutputPath="$pwd\out\Company.MainApplication"
I get the following error output (there's no more information, I ran with /verbosity:diagnostic)
The target "Company.MainApplication" does not exist in the project.
What I Need
The command fails on any project with a dot or dots in the name. I tried with many combinations of working directories and properties. I tried several ways of escaping the property values. I also tried running the command from a <Task> in a targets file.
I need to know either
A) How to fix this command to work property
B) How to achieve the same output with minimal friction
Try using an underscore as an escape character for the dot in the target parameter, e.g.
msbuild /target:Company_MainApplication /property:OutputPath="$pwd\out\Company.MainApplication"
Specify the target after the -target: switch in the format :. If the project name contains any of the characters %, $, #, ;, ., (, ), or ', replace them with an _ in the specified target name.
https://learn.microsoft.com/en-us/visualstudio/msbuild/how-to-build-specific-targets-in-solutions-by-using-msbuild-exe?view=vs-2019
Dan Nolan's answer and comments are correct. Just want to supplement the Microsoft documentation.
The /targets: switch is to identify a <Target to run in the project file. You need to supply your .csproj file as a an argument that is not prefixed by a /xx option marker.
You might also want to work based on the .sln file. In that case, you still dont specify the project in the .sln to build in this manner. I'll leave you to search up the correct syntax in case that's what you end up doing.