Here is a silly simple question that's been running on mind. Does importing a library copy code to the current file when compiling or just allows reference to the library code.
It's only referencing. Each library is treated as a unique set of declarations, identified by the URI used to specify the library. Every other library which imports a library will see the same declared or exported declarations. Those name of those declarations then become available in the importing library's import scope.
A part file, on the other hand, is included literally in the including library.
Related
Note that imports are generally discouraged in the language. When working on your own code, prefer alias to import.
I found this statement in the documentation but further explanation is not available there.
Few reasons:
import creates compile time dependency between these modules, which mean that importing module compilation need to wait until imported module is compiled. alias do not create such dependency.
imports often bring too much into scope of the module and can cause compilation conflicts when the imported module will add more functions (you cannot define function with the same name as the imported function).
I'm little bit confused about which style of import should I use when importing implementation libraries (code under src/lib) from another libraries (and tests) in my own package?
The docs recommends the opposite options.
In pub docs, it says:
When you use libraries from within your own package, even code in src, you can (and should) still use package: to import them.
But in "Effective Dart", it says:
When referencing a library inside your package’s lib directory from another library in that same package, use a relative URI, not an explicit package: URI.
In the end, which style should I use in such cases:
import implementation library (under lib/src/) from with public library (under just lib/)?
import implementation library (lib/src/foo.dart) from within its test (test/src(?)/foo_test.dart)?
import public library (lib/foo.dart) from within its test (test/foo_test.dart)?
Is there any recommendation how to import local files. In my case I would have 2 options:
import 'package:workshop/feed/item.dart';
import 'item.dart';
I haven't found anything on that on the guide Effective Dart: Style nor on Google search.
There are at least two different recommendations, depending on who you ask.
Either works, I personally recommend the latter, shorter, variant.
It is sufficient and it avoids the issue of hard-coding your package name into every file. If you ever want to rename the package, that will be a drudge.
There is one issue which makes some people recommend the former format.
If you import a package library using a non-package: URI, say by having a file in the bin/ or test/ directory do an import like:
import "../lib/mylib.dart";
then that library is now imported using two different URIs:
package:mypkg/mylib.dart and
file:///somewhere/mypkg/lib/mylib.dart
Since Dart identifies libraries by their import URIs, these two imports will be treated as different libraries, each with their own global and static variables, which just happen to have the same source code. That's an annoying problem, and can be hard to debug. If you use the long package:... import everywhere, then at least the issue is restricted to the first library you import. If you use a relative import, import "src/helper.dart";, then that library will now also exist in two versions:
package:mypkg/src/helper.dart and
file:///somewhere/mypkg/lib/src/helper.dart
The real issue here was the first import which contained a /lib/ in the path. You must never have such an import. Using package: URIs for all imports may reduce the issue, but not remove it.
I recommend using the relative path, and making sure that you never have a /lib/ in any import path. Libraries in the /lib/ directory of a pub package are package libraries and should be referred to using package: URIs. If you do that, then relative URIs will be resolved against the package URI and again be a package URI, and all is well.
I'm having an issue implementing modules for my particular build configuration. I have a bunch of dynamic frameworks that I would like to add module map files to so that they can be naturally imported into Swift without having to use Objective-C Bridging Header files. The issue that I'm having is as follows:
I have multiple modular frameworks:
Framework.framework (base framework, required by all components)
Framework.Component1.framework
Framework.Component2.framework
... etc
I would like to be able to write a module map for each framework that uses this dot notation for the module naming (for backwards compatibility, among other reasons) but Xcode isn't allowing me to name whole modules with the dot syntax since the dot syntax is reserved for Submodules.
I've tried creating an umbrella framework that contains all of different components and writing a single module map for that, but given that the frameworks are dynamic this necessarily bloats the final binary size if the user isn't using all of the frameworks inside of the umbrella framework.
Are there any solutions that would allow me to use this dot syntax while having separate module map files for each of the frameworks?
Thanks!
Go with the umbrella framework strategy.
Then, for submodules that are "optional" in your umbrella framework (maybe even all or most of them) set the submodule declaration to explicit. This means the consumer must import the submodule explicitly in order for it to be loaded. This is what I've done in the past to import a very large C library into Clang's module system and it worked well enough.
The docs are okay, but not great. However, they do go over this case pretty well: https://clang.llvm.org/docs/Modules.html#submodule-declaration
I want to include Microblink's PDF417 framework into my library. Library project compile and work fine but when I use MyLibrary.a file in my application I've got "undefined symbols for architecture armv7" error. Any ideas? Can I include custom framework to library or this isn't possible.
Trojanfoe's answer is correct for your case. But in general, the answer depends on the type of the library inside the framework.
iOS/MacOS framework is a just a collection of a library together with all relevant header files. This makes including the library into other projects much easier, because the whole framework can be included at once, thus eliminating the need to modify linker and header search paths and linker flags.
Library itself can be either a static library or a dynamic/shared library. Framework can contain the library of any type, there are no limitations in that regard.
If the library in framework is static, then all the objects from that library are copied into target product at compile time. If the target product is a static library (MyLibrary.a in your case), additional linking with the framework in the application is not needed, because all the objects are contained in MyLibrary.a
If the library in the framework is dynamic, then objects from that library are loaded at load-time or run-time, not at compile time. Because of that, frameworks of that type need to be linked with end applications also.
In your case, pdf417 framework contains a dynamic library, which means you will also have to include that framework into your end application.
I'm a developer on Microblink's PDF417 SDK. The thing is, we can provide our library in any format. The format we have chosen in our Github repository is an .embeddedframework which contains a dynamic library together with all resource files because that makes including the framework into Application projects very simple. If you have a use case which requires a different format, we invite you to contact us on https://help.microblink.com/hc/en-us
A static library is just a collection of object files (a bit like a zip file without compression or hierarchy) and cannot hold information about any dependencies it might have.
Therefore you have to link the final executable binary against both your library and the dependent framework. The same applies if the dependency was a static library, dynamic library or framework.