I know that lib/ is where we put all our library files and /bin is where we put our entrypoint for our command-line app. I know both of them are public lib/ and bin but i'm unable to understand the convention of using lib/src which according to the official docs should contain: implementation code
lib/ is the directory that contains shareable code.
It can be shared
to other top-level directories like bin/, web/, example/, test/, tool/, ... in the same package
to other packages that have this package as a dependency.
lib/src by convention contains the private implementation of the public API exposed by lib/ or lib/xxx where xxx is not src.
bin is reserved for command line apps and contains the Dart entry point scripts to execute them (the files that contain main() {...}).
In pubspec.yaml you can define executables https://www.dartlang.org/tools/pub/pubspec#executables that allows you to run scripts from bin/ by just executing foo to have dart somePath/bin/foo.dart executed (using pub global activate my_package_with_foo).
See Pub Package Layout Conventions - Implementation files
The libraries inside lib are publicly visible: other packages are free to import them. But much of a package’s code is internal implementation libraries that should only be imported and used by the package itself. Those go inside a subdirectory of lib called src. You can create subdirectories in there if it helps you organize things.
You are free to import libraries that live in lib/src from within other Dart code in the same package (like other libraries in lib, scripts in bin, and tests) but you should never import from another package’s lib/src directory. Those files are not part of the package’s public API, and they might change in ways that could break your code.
When you use libraries from within your own package, even code in src, you can (and should) still use package: to import them.
Related
I want to run the example project which is available for free from this link. It is a simple FFT library and needs no compiler. In it, there is an example c file with its required header files and .c files.
When I try to run it in Vivado SDK I get errors of multiple definitions of fft and ifft. How can I run this example inside SDK?
What I had done is created an empty application project and then imported all these files inside src folder and then selected build the project option but didn't succeed in building and running the project.
I guess, looking at the ufft.zip archive, that you've tried to link files issued form the compilation of fft-dit.c and fft-dif.c.
Both files define ftt functions using differents method (see README).
You have to choose betwen using ftt-dif.c or ftt-dit.c, not both.
This is the same for itt-dif.c and itt-dit.c, choose one, not both.
We have a program people can compile on their machines. It has an HTTP interface but can also be invoked by command line.
In order to provide some nice-looking error pages for HTTP clients, we want to provide error pages. We are using a very simple solution with go's html/template package.
So in order for the program to find the templates, we currently do:
func init() {
prefStr := "path/to/http/tmpl"
pathPrefix,err := filepath.Abs(prefStr)
if err != nil {
log.Warn("Template path %s is not available!", prefStr)
}
pathPrefix + "/err.html"
}
Now when debugging the app, this usually works well - we are in the package's root directory, so filepath.Abs() resolves correctly, like so:
$GOPATH/github.com/user/repo/path/to/http/tmpl (expanding $GOPATH correctly)
But when we invoke the app via executable from the command line, this doesn't work. The command line could of course be invoked from anywhere on the filesystem, for convenience for example to provide a file in the current directory as a parameter.
In short, running /some/other/path/on/fs/our-executable filename.txt results in the init() function above breaking due to wrong concatenation of the directory: it takes /some/other/path/on/fs/ to create the absolute path, which is wrong. Thus it crashes with
panic: open /some/other/path/on/fs/path/to/http/tmpl/err.html: no such file or directory
I've searched and so far only found this:
How can I open files using relative paths in Go?
But this exactly doesn't apply for us.
Another solution proposes to bundle compiled go resources, but this seems rather odd as the error pages are html text.
We've also tried
https://stackoverflow.com/a/31464648/169252
but it has the same effect.
How can we make sure that the paths are always resolved correctly? This seems rather something which shouldn't be too difficult to be done, but we haven't managed so far.
EDIT: This is not an exact duplicate of the question How can I open files using relative paths in Go?. As already mentioned in my question text, I already had looked it up myself. It suggests to use filepath.Abs(). But as laid out in my question, for us this doesn't work, as if our executable is called from different places, filepath.Abs() doesn't return the same value, and thus doesn't work for us.
I think your challenge here is that people can install the program anywhere on the disk and the program will have to be smart enough to know where it is later on.
One of the common approach that I have seen is that people typically use environment variables to anchor them to the application's installation path. I believe you may have seen environment variables with naming pattern of *_HOME like JAVA_HOME, MAVEN_HOME and their values are always filepath to the installation place.
I guess you can do the same here. Force your users to have MYAPP_HOME variable define and at the start of the application make sure that it is set or else throw an error saying MYAPP_HOME is not set.
Then all you need to do would be a simple lookup of the value for MYAPP_HOME + /http/tmpl to source for the template html files.
Example:
package main
import "os"
func main() {
// Assuming MYAPP_HOME has been verified that it is set
// Then:
tmlPath := os.Getenv("MYAPP_HOME") + "/http/tmpl/"
errTml := tmlPath + "err.html"
}
If you're not keen on using the current working directory, or passing the directory in, you can find the absolute executable path by calling os.Executable from the os package.
appPath, err := os.Executable()
The os package will generally contain os specific stuff like how to get the current working directory. It's worth looking through the pkg docs and list of packages at golang.org if your'e ever stuck, as they are pretty good typically you'll find an answer there.
https://golang.org/pkg/os
Another approach you can take here if users install with go get is to rely on the fact that your templates will be installed with the pkg under GOPATH, so you can always find them at $GOPATH/src/your/project/path/templates (or ~/go the default gopath now that it is not strictly required).
The safest way is probably to bundle them with the binary in a virtual file system as this means you depend on nothing external and don't care where your app is hosted or even if it has access to files at all.
I recommend using a relative path in this case.
According to your description, it seems like you are developing a web application. While it works fine on individual developer's machine, you need to be mindful that your application can be deployed under any directory on your production server. You cannot determine where you app is going to be deployed, but you can always determine where static files are relative to the root directory of your app.
When you invoke your app in the command line, you should have all the required static files copied to the same relative path exactly the same with your development environment. My typical structure is:
project/
|- config.json
|- main.go
|- package1/
|- package2/
|- static/
|- templates/
| |- index.html
| |- base.html
|- css/
|- javascript/
|- image/
When you are ready to run your application from command line, be sure to copy your config.json and the static/ directory to the same level as your executable binary. Then all you need to do is to use relative paths in your code without any nightmares.
For the records: as we just have two templates, we resorted to store them as strings in a go file so that they get compiled. Our html templates are very simple, so this is a reasonable way to do it.
I'm building a project that uses cmake.
The project uses three shared libraries .so files.
In the CMakeLists.txt file I've added the these lines which link the shared libraries to the executable.
project (lwm2mclient)
LINK_DIRECTORIES(/home/mraa-master-built/build/src)
LINK_DIRECTORIES(/home/libi2capi)
LINK_DIRECTORIES(/home/libtca6424a)
target_link_libraries (lwm2mclient libmraa.so m libi2capi.so libtca6424a.so)
However, one of the shared libraries libtca6424a.sodepends on libi2capi.so i.e. it uses methods that are defined in it.
So when I'm building the cmake project I get an error like this saying that the .so file cannot find the method which is defined in the other .so file libtca6424a.so.
Could somebody suggest a solution?
/../../lib/libtca6424a.so: undefined reference to `i2c_write_byte_data'
Please try
target_link_libraries (-Wl,--start-group lwm2mclient libmraa.so m libi2capi.so libtca6424a.so -Wl,--end-group)
or change the order of the libraries
I have a c language program that has the following structure:
src/main/c/main.c
src/main/headers/main.h
src/module_1/c/module_1.h
src/module_1/headers/module_1.h
...
src/modulen/c/module_n.c
src/module/headers/module_n.h
In the gradle script I have defined:
components {
module_1(NativeLibrarySpec)
...
module_n(NativeLibrarySpec)
main(NativeExecutableSpec){
sources{
c.lib library: "module_1", linkage: "static"
...
c.lib library: "module_n", linkage: "static"
}
The reason of using this structure is to facilitate creating unit tests for each module separately.
The problem comes with the inclusion of the .h files from the modules in the main or in other modules (there are some dependencies between them). I haven't found a way to make the headers of a module available to other modules. I would actually like to make them all "global" to the project (that is, automatically added to the source set for any module).
Thanks in advance
I do not know gradle but may give you some general advise.
I haven't found a way to make the headers of a module available to other modules.
You could make a central directory (repository) for all .h files of your project, for example src/include. The header files of each module can be placed there (in the version of the curent baseline).
I would actually like to make them all "global" to the project (that is, automatically added to the source set for any module).
The above repository can support that. However, including a header in a source file is a manual task. It is also wise not to include all headers into a source file; it may only need a few.
I'm developing a static library in C++ using Xcode. I have an Installation Directory set where it copies all of my public header files, but when I compile it just copies all the headers into one directory. Is there a way to tell Xcode to preserve the directory structure of my header files? Thanks in advance!
I also needed to preserve the header file directory structure for a C++ library project and I finally managed to do it. It is ridiculously complicated with XCode, compared to the simple nature of the task. The key is to create "folder references" at first, then to copy the header folders in an extra build phase and afterwards to delete .c/.cpp-files from these exported header folders with a script, because XCode will not only copy the .h-files.
I've written a blog post here on how to all achieve that, because it's more tricky in detail. You might also want to check out an example XCode project that I've pot on github.
When you add files to your project, you have to choose next parameter on an additional window "Create folder references for any added folders". And then all your files will have fixed path for your files and will save structure after compilation.