This question already has answers here:
Can I create shared test utilities?
(2 answers)
Closed 3 years ago.
My Go project code structure looks something like this.
project
|
+-- x_test.go
|
+-- sub-directory
| |
| +-- y_test.go
x_test.go has some struct and methods that are used only for test purposes.
These struct and methods are un-accessible in y_test.go.
Is there a way test files can be imported in sub-directories? I cannot move the file x_test.go to the sub-directory as it makes use of some interfaces defined in the root level directory.
The file y_test.go cannot be put at the root level as it is using some instances defined in sub-directory, and this would cause a cyclic dependency.
Is there a way I can make the methods and struct defined in x_test.go visible to y_test.go?
Everything works fine if I don't treat x_test.go as a test file. i.e, I rename it to just x.go
Is there a way I can make the methods and struct defined in x_test.go visible to y_test.go?
No.
Related
Using coc.vim feature (coc-references) on the name of classA or any other one, it seems to search and find references only on local file ClassA.cpp, not on entire project folders' sources.
ProjecT-Root
SubfolderA/classA.cpp
SubfolderB/classB.cpp
classeC.cpp calling new classA
The command (coc-references) report me only classA.cpp occurrences.
I would like all references reported on entire project. If i use coc-references-used, it's the same.
Thank you
Nicolas
It's language server's issue, coc-references requests textDocument/references to language server, LS returns results and coc.nvim display them.
I spent quite a lot of time thinking about how should I organize a good modular structure for my Qt C++ project. Unfortunately, I did not find a complete example on how to do it right (am I missing something?), so I am looking for an advice. So far, I came with the following assumptions:
I would like to have separate directory for modules, because each of them may be used in sevaral apps.
I would like to have unit tests for each module.
I also thought that keepng tests right inside module's folder is a good decision, because if I want to move or rename a module, nothing will be broken, because I can use relative paths to the module's sources in my tests.
So my desired project structure looks like this:
|project_root
|src
src.pro (TEMPLATE = subdirs)
|apps
apps.pro (TEMPLATE = subdirs)
|my_app
my_app.pro (TEMPLATE = app)
main.cpp
...
|modules
modules.pro (TEMPLATE = subdirs)
|my_module
my_module.pro (TEMPLATE = ???)
|tests
tests.pro (TEMPLATE = subdirs)
|MyClass1Test
MyClass1Test.pro (TEMPLATE = app)
tst_myclass1test.cpp
|MyClass2Test
MyClass2Test.pro (TEMPLATE = app)
tst_myclass2test.cpp
MyClass1.h
MyClass1.cpp
MyClass2.h
MyClass2.cpp
My first question is - is this structure good in context of Qt Creator's logic? Am I doing something completely wrong?
My second question is about implementation of my_module.pro. Which template should I use here? I was playing around four types of project templates: subdirs, lib, aux, and I could not manage to organize my module structure as above (that's why I am looking for a logical error). There are some reasons for that:
If I use TEMPLATE = subdirs for my_module.pro, Qt Creator does not recognize any files inside it (MyClass1.h, MyClass1.cpp, ... disapper from project structure) and I can't build a library any more
If I use a TEMPLATE = lib or TEMPLATE = aux, then I'm unable to create tests subproject in this folder
So my third question is: How should I organize my project in a good way to overcome these issues?
I'm using jade with gulp to generate a static html prototype but having problems with relative links to assets like css files from jade templates located in subdirectories.
As this is a prototype and team members should be able to take a look at it quickly,
the files should be usable out of the box by using just a browser with no further configuration
no server is used
the files should be viewable on different machines
Project Structure
The source folder structure is like this:
src
|
|--first.jade
|
|--subdirectory
| `--second.jade
|
|--templates
| |--layout.jade
| `--head.jade
|
`--css
`--styles.css
first.jade and second.jade both extend layout.jade.
layout.jade includes the partial head.jade, which contains a relative link to styles.css:
head
link(rel='stylesheet', href='css/styles.css')
gulp generates this structure (which is how I want the project to be structured, so this shouldn't change):
build
|
|--first.html
|
|--subdirectory
| `--second.html
|
`--css
`--styles.css
Problems with this approach
The relative link to the css does not work for second.html as it is
in a subdirectory. The link in the rendered html is
<link rel="stylesheet" href="css/styles.css">
but it should be this in order to work:
<link rel="stylesheet" href="../css/styles.css">
I have to use different extend statements in first.jade and
second.jade, which is not a real problem but rather annoying.
first.jade:
extends templates/layout.jade
second.jade:
extends ../templates/layout.jade
Possible solution (which quite doesn't fit)
One solution to problem one could be to use a base tag in head.jade like this:
base(href='/Users/myusername/build/')
This works perfectly, but only on my machine, and only if I leave the project folder at the current location. This won't work for anyone else as the path used in the base tag will not be found on their machine.
Question
Is there some clever way to solve problem one with just using jade? Bonus for problem two...
It seems to me that the problem at hand should be a very common one, so I might have overlooked it in the docs or something.
This is what I came up with: Using the base tag in combination with jade variables.
head.jade now includes a block containing a variable to set the base path with a default value of '.':
block basetag
-var base = '.'
head
base(href='#{base}')
link(rel='stylesheet', href='css/styles.css')
This works for all templates in the root directory by default.
For all templates in a subdirectory, the base variable can be set to '../' like this:
extends ../templates/layout.jade
block basetag
-var base = '../'
I got function to make relative path from dividing slash with current path.
-
// Count depth directory hierarchy
var depth = (relativePath.match(/\//g) || []).length;
var relativeRoot = new Array(depth + 1).join( '../' );
visit my repo
The directory structure in Ember App Kit dictates that all controllers go in the '/app/controllers/' directory; handlebars templates go in the '/app/templates/' directory, and so on.
However, my team are currently developing an Ember application in which the number of functional areas (and therefore source files) is continually growing, so we want to create subdirectories under these directories for our controllers, templates, etc, rather than group everything in the same directory.
We have done this for one functional area by organising our controller and corresponding handlebars template in the following manner:
/app/controllers/availability/availability.js
/app/templates/availability/availability.hbs
So far, the only way we have been able to get this approach to work (i.e. to link our controller and template in this nested directory structure) is to create the following route:
this.route('availability.availabilty', {path: "/availability"});
This has the side-effect of Ember creating the following for us:
Route Name: availability.availability
Route: AvailabilityAvailability
Controller: AvailabilityAvailabilityController
Template: availability/availability
URL: #/availability
The word 'Availability' is duplicated in the resulting Ember controller to echo our nested availability/availability directory structure.
Does anyone know of a better way of organising an application in subdirectories within Ember App Kit? This surely must be a common requirement for applications with a large number of source files.
We would wish, for example, for Ember to create the following for us:
Route Name: availability.availability
Route: AvailabilityAvailability
Controller: AvailabilityAvailabilityController
Template: availability/availability
URL: #/availability
Many thanks
From the documentation on Nested directories http://iamstef.net/ember-app-kit/guides/naming-conventions.html it seems that you can do what you're looking to do with a single tweak. Instead of putting availability.js in the availability subfolder it should be one directory up, then all the sub availability controllers are placed in that subfolder.
+-- app
+-- controllers
| +-- availability
| | +-- edit.js
| +-- availability.js
+-- app
+-- templates
| +-- availability
| | +-- edit.hbs
| +-- availability.hbs
Please look into ember-pods.
http://cball.me/organize-your-ember-app-with-pods/
This is a way to structure your ember application in a way you were desiring.
So how exactly does one separate classes by path in Doxygen? I have tried with groups and sections,but for some reason, it would always combine classes with same name.
Current file structure is as following:
Trunk
|
+-> Client -> DemoClass.h
|
+-> Server -> DemoClass.h
|
+-> Shared -> OtherClass.h
Problem is I don't want a 1x DemoClass in doxygen that contains all the functions combined i want 2 seperate sections/class as in Server/DemoClass, Client/DemoClass.
This is a known limitation, see bullet 4 of http://www.doxygen.org/manual/trouble.html.
I recommend to make separate projects, one for the server and one for the client, as they can never be legally in one executable anyway, or use namespaces.
File names can be the same, that's not a problem.