I'm learning Go with the specialization Programming with Google Go. It has several courses, each of which has several modules.
My project looks like the following (made with https://ascii-tree-generator.com/):
google-golang/
├─ .github/
│ ├─ workflows/
│ │ ├─ ci.yml
├─ golang-getting-started/
│ ├─ module1/
│ │ ├─ main.go
│ │ ├─ main_test.go
│ ├─ module2/
│ │ ├─ trunc/
│ │ │ ├─ main.go
│ │ │ ├─ main_test.go
├─ .gitignore
├─ README.md
I'd like to run all the tests in the *_test.go files for every commit, and it's not clear to me how to do that from the root directory (google-golang). I don't see a need for one module to import another as the exercises can be done independently. This question has two answers, one suggests using submodules, another recommends using Go workspace, but neither provide specific instructions that someone new like me can learn from.
I'm not asking for help on GitHub Actions, I know how to write those. I'm looking for one or more commands that'll find and run the tests.
You seem confused about what a module is. The rule of thumb is, one go.mod file equals one module. Go Wiki, gomod:
A module is defined by a tree of Go source files with a go.mod file in the tree's root directory.
Based on your directory tree shown in your question, there is no go.mod file in sight, hence nothing there is a Go module. As a matter of fact, if you attempt running a module-aware command from google-golang or golang-getting-started you'll have:
go: go.mod file not found in current directory or any parent directory; see 'go help modules'
If you want to run all tests from the root of a multi-module repo, as the title of your question says, with Go 1.17 you can:
init the sub-modules:
$ cd google-golang/golang-getting-started/module1
$ go mod init example.com/module1
$ cd ../module2
$ go mod init example.com/module2
use the trick suggested by Cerise Limón from the root dir of the multi-module project
$ cd google-golang
$ find . -name go.mod -execdir go test ./... \;
If you don't actually care about keeping the sub-repos as separate modules, you can init a module in the root repo and run all tests from there:
$ cd google-golang # or google-golang/golang-getting-started/
$ go mod init example.com/mainmod
$ go test ./...
...however, even this hack works right now, it doesn't make a lot of sense, because your repos named moduleN have main.go files, whose packages are supposedly named main, in each of them. So they are indeed organized as separate sub-modules.
Related
I want copy a folder containing subfolders in SAS:
Example of the folder that I want copy :
folder_to_copy/
├─ sub_folder_1/
├─ sub_folder_2/
│ ├─ file_sub1
│ ├─ file_sub2
│ ├─ file_sub3
├─ file1/
├─ file2/
I've try
option xwait xsync;
X copy "folder_to_copy" "new_folder";
But this copy only file1 and file2
and
data _null_;
call system ('cp folder_to_copy new_folder');
run;
doesn't work too, this does nothing
Use cp -R if you're using Linux.
x 'cp -R folder_to_copy new_folder';
Use robocopy /E if you're using Windows.
x 'robocopy folder_to_copy new_folder /E';
I'm working in VSCode with C++. I want to use and compile files from different folders, I made an example of what I want to do https://github.com/ChrisvdHoorn/Cplusplus_project (renamed .vscode to vscode so that I could upload to github, is actually called .vscode (!))
Cplusplus_project
└───.vscode
│ │ c_cpp_properties.json
│ │ launch.json
│ │ settings.json
| | tasks.json
│
└───include
| │ TestLib.h
|
└───src
| main.cpp
| TestLib.cpp
main.cpp uses TestLib.h and Testlib.cpp.
This compiles fine when main.cpp, TestLib.h and Testlib.cpp are placed directly in the worspace, but not in the file structure above.
I came across similar questions on the internet, and the general answer was that you need to add something like "-I${workspaceFolder}/include", the the args section of the compiler. I tried this, but no luck.
Any help is very welcome :)
Sub question: I use the playbutton to compile and run the code. Is this actually running the task from tasks.json? I couldn't really find a definitive answer on it online.
For business-related reasons, I am not able to split my infrastructure using versioned modules. As it is still beneficial to split the environments, and I would like to avoid the copy/paste root modules, which are basically just instantiation of child modules, over multiple directories, each representing its own environment, I would like to specify the source of root module in terragrunt.hcl
To make life easier, I have built a small part of the current infrastructure, just with a single module to speed up the development.
The current structure of the project looks like this:
├── config
│ ├── common.tfvars
│ └── terragrunt.hcl
├── environments
│ └── dev
├── infrastructure-modules
│ └── ecs
├── terraform-modules
│ ├── terraform-aws-ecr
All my infrastructure is described in infrastructure-modules/ecs/*.tf files, which are basically just instantiating child modules declared in terraform-modules/terraform-aws-*/.
With that, I can simply execute the terragrunt (terraform commands) from the infrastructure-modules/ecs directory.
To have a possibility to create the same environment in another account, I have introduced a new directory environments/dev/eu-central-1/ecs as shown on tree output from the root directory.
The environments/dev/eu-central-1/ecs, consists just of two files, terragrunt.hcl and common.tfvars.
I guess, that the usage of the common.tfvars is quite self-explanatory, where my terragrunt.hcl consists of remote_state {} and terraform {} blocks.
The important part of the terragrunt configuration file:
remote_state {}
terraform {
source = "../../../../infrastructure-modules/ecs"
{...}
}
Above I am basically referencing my root modules, declared in infrastructure-modules/ecs/*.tf. Where my root modules are instantiating child-modules declared in terraform-modules/terraform-aws-*/.
Child modules from infrastructure-modules/ecs/*.tf are instantianed like this:
module my_module {
source = "../../terraform-modules/terraform-aws-*"
{...}
}
In an ideal world, I would be able to execute terragrunt (terraform) commands from environments/dev/eu-central-1/ecs directory, but as I am using local (relative) paths, this is failing during the initialization of the modules, as the root module my_module loads the child module with following relative path:
module my_module {
source = "../../terraform-modules/terraform-aws-*"
{...}
}
This is causing a module instantiation in environments/dev/eu-central-1/ecs to fail as the relative path is different, based on parent module instantiation.
Initializing modules...
- my_module in
Error: Unreadable module directory
Unable to evaluate directory symlink: lstat ../../terraform-modules: no such
file or directory
So far, according to the documentation, path_relative_*, should be able to return the relative path between the path specified in its include block and the current terragrunt.hcl, but the problem here is that I am not having any include {} block(s) within my terragrunt.hcl files and thus this approach doesn't works. Symlinks are the last option.
EDIT
If I inspect the .terragrunt-cache/* on path environments/dev/eu-central-1/ecs I can confirm that all the "root" modules have been downloaded(copied over) into cache directory.
However, the module is being instantiated like this, and it tries to fetch the actual modules (Terraform modules) from directory two levels above.
module my_modules {
source = "../..//terraform-modules/terraform-aws-ecr"
So basically, I need to tell Terragrunt to download/fetch the modules from other path.
EDIT 2:
Inspecting .terragrunt-cache in the directory where I am running init shows, the the terraform-modules are never downloaded in the
terraform-infrastructure/environments/dev/eu-central-1/ecs/.terragrunt-cache/.
If I change my terraform-infrastructure/infrastructure-modules/ecs/ecr-repos.tf, from
module ecr_lz_ingestion {
source = "../../terraform-modules//terraform-aws-ecr"
{<MODULE_ARGUMENTS>}
}
}
to:
module ecr_lz_ingestion {
source = "../../../../../../../../terraform-modules//terraform-aws-ecr"
{<MODULE_ARGUMENTS>}
}
}
Terraform is able to initialize the child-modules as I have given a relative path to terraform-modules/ in the directory root, which is obviously a workaround.
Somehow I am expecting the Terragrunt to download both directories, terraform-modules and infrastructure-modules for the relative paths in module instantiation to work.
Based off the additional information you provided, I understand that this is your current directory structure:
terraform-infrastructure
├── config
│ ├── common.tfvars
│ └── terragrunt.hcl
├── environments
│ └── dev
│ └── eu-central-1
│ └── ecs
│ └── terragrunt.hcl
├── infrastructure-modules
│ └── ecs
├── terraform-modules
│ ├── terraform-aws-ecr
│
├── terragrunt.hcl
Notice the terragrunt.hcl in the parent directory that I added.
That terragrunt.hcl is considered the parent file and can include code that can be shared among other terragrunt files.
It can include something like this:
remote_state {}
In your eu-central-1/ecs folder, add the following to your terragrunt file:
include {
// searches up the directory tree from the current terragrunt.hcl file
// and returns the absolute path to the first terragrunt.hcl
path = find_in_parent_folders()
}
// using the path relative from the path stated in the include block
terraform {
source = "${path_relative_from_include()}//infrastructure-modules”
}
This should keep relative pathing intact when child modules are instantiating.
Edit:
From your GitHub issue, it would be best to either move the double slash to somewhere the modules share a common path with. Either that or to just consolidate your modules into a single folder.
Our C++ project is organized in several modules (== subfolders) and headers are placed next to the .cpp files:
CMakeLists.txt
src
│
└───folder1
│ │
│ └───subfolder1
│ │ MyClass1.h
│ │ MyClass1.cpp
│ │ ...
│
└───folder2
│ │
│ └───subfolder2
│ │ MyClass2.h
│ │ MyClass2.cpp
│ │ ...
Include directives are always defined relative to the folder src and not relative to the code file e.g. in MyClass1.cpp:
#include "folder1/subfolder1/MyClass1.h" // even the own header is defined semi-relatively
#include "folder2/subfolder2/MyClass2.h"
MyClass1::MyClass1() {
// some code
}
I recently noticed that cppcheck (version 1.89) has problems with this and does not correctly
resolve macros defined in a header file -> False complaints about correct code
find problems with class member initialization (e.g. MyClass::MyClass() : _foo(_foo) {}) -> No complaints about incorrect code
When providing -I src to the cppcheck CLI, macros are correctly identified and actual issues like above are found, but analysis time skyrockets from 2 to 20 minutes.
I suspect, that by providing the whole source code again via -I, the files are all re-parsed as header files. Unfortunately, I don't have a specific include/ sub folder which I can use here. What is advised here? I am already using multiple jobs: -j 4.
After some further investigation, this might actually not be a valid question:
I manually took all header files and copied them to a separate folder: find . -type f \( -iname \*.h -o -iname \*.inl -o -iname \*.hpp \) -exec cp --parents \{\} ./../__cppcheckWorkaroundInclude \; which I then provided via -I to cppcheck
The check still took 20 minutes, so my assumption that cppcheck wrongfully scans too much is invalid - it actually takes this long because it is a lot of code.
So providing -I __cppcheckWorkaroundInclude or -I src to cppcheck did not make a difference - at least I did not observe one. Meaning, that -I works as expected
To solve the performance issues (I run the job inside a CI and 20 minutes is a lot of time which I would rather spend on executing automated tests), I did the following:
Reduce the checked configurations --max-configs=5
Used incremental checking via --cppcheck-build-dir=CppcheckBuildDir
To integrate this in our Gitlab CI, I had to cache this directory:
cache:
paths:
- CppcheckBuildDir
and before the cppcheck call, the directory has to be created (but with the -p flag because the dir might already be there, taken from the cache!):
mkdir -p CppcheckBuildDir
I have a program, that works on Linux using SDL-bgi. I have downloaded the SDL-bgi binaries from http://libxbgi.sourceforge.net/ , and can get it to compile, but I can't get it to link (giving me"undefined reference to ... errors). The download provides a DLL, but according to the answer to this question, I need a .lib. I can't find any .lib anywhere n the download.
Here is the output of tree /f in the folder extracted:
│ AUTHORS
│ BUGS
│ build.sh
│ ChangeLog
│ CMakeLists.txt
│ INSTALL.md
│ LICENSE
│ README.md
│ sdl_bgi.spec
│ TODO
│ VERSION
│
├───bin
│ ├───CodeBlocks
│ │ SDL_bgi.dll
│ │
│ ├───Dev-Cpp
│ │ SDL_bgi.dll
│ │
│ └───Mingw64
│ SDL_bgi.dll
│
├───doc
│ functions.md
│ functions.pdf
│ howto_CodeBlocks.md
│ howto_CodeBlocks.pdf
│ howto_Dev-Cpp.md
│ howto_Dev-Cpp.pdf
│ sdl_bgi-quickref.pdf
│ sdl_bgi-quickref.tex
│ SDL_bgi_logo.png
│ SDL_bgi_logo.svg
│ turtlegraphics.pdf
│ turtlegraphics.tex
│ using.md
│ using.pdf
│
├───src
│ graphics.h
│ Makefile
│ Makefile.CodeBlocks
│ Makefile.DevCpp
│ SDL_bgi.c
│ SDL_bgi.h
│
└───test
[... a bunch of c files]
I am trying to link to the library from where it is, instead of C:\CodeBlocks\MinGW\bin as recommended by the docs, because I don't have the right privileges.
First Method if you don't have installed old bordland graphics interface in Codeblocks then use this method other-wise you get error like multiple declaration because both library use same function declaration
step:1- Create a New c console project name it what ever you want then paste the
files from include folder from the zip below and paste it here
C:\Program Files (x86)\CodeBlocks\MinGW\include
then paste libsdlbgi.a from the zip file to this path
C:\Program Files (x86)\CodeBlocks\MinGW\lib
SDLBGI.zip
step:2-Go to the codeblocks then go to setting then select compiler go to linker option and click add then browse to previously pasted libsdlbgi.a file then add it then go to search directory linker and do same with libsdlbgi.a
again.
Step:3-Write any simple program and built and compile and run it.
Second method if you want both bgi and sdl bgi
Follow all the steps carefully to get it works
Step:1- Simply create a new project in Code-Block using SDL2 from the category click enter and give a title to the project then click next and finish to create to new project.
Step:2- Go to your directory where you have created your project then copy these files
'SDL_bgi.c' , 'SDL_bgi.h' and 'sdlbgidemo.c' , 'logo.bmp' from the "SDL_bgi-2.2.4" [src folder] and [test folder] to project folder.
Step:3-First delete default main.cpp file from codeblock project then add "sdlbgidemo.c" into the project then click ok in next window in CodeBlocks which ask for
select target file to "debug" and "release"
Step:4-select the sdlbgidemo.c in codeblock then open it in the code editor then change the #include <'graphics.h'> header to #include "SDL_bgi.c"
Step:5-Last Step press built and run button it will built and run the project and you will probably see the previously pasted logo.bmp on the screen then you can see demo of all SDL_bgi Library funtions.
Here it is Code-block project file [zip] for you with all the necessary modification so you can easily run it using Code-blocks.
[Code-Blocks Project File.zip]
if you don't want to repeat step:2 and step:3 every time you created new project you follow Step:5 to solve this problem.
Step:6-First go to the directory where you have installed your Codeblocks then browse through [Mingw] then [include] folder in this folder you can simply copy 'SDL_bgi.c' , 'SDL_bgi.h' or if you have already installed Old Borland Graphics library [BGI] then you have to create separate folder for SDL-BGI and have to paste all files which i tell you earlier in this newly created folder then if you want you to use or include these files in your project simply
type these lines #include "SDL_bgi.c" or #include "[Previously created folder]/SDL_bgi.c" to run your program.
Here is the link of zip file which have some screen shot of all the steps we have taken so far...
[ScreenShot.zip]
I hope this solve your problem and save your time.
At Last
That's all folks