I would like to use objectbox inside a swift package, not inside a project, but on the documentation I couldn't find a procedure to follow to complete the operation.
I found no problem adding the library as a dependency:
.package(url: "https://github.com/objectbox/objectbox-swift", from: "1.8.0")
My problem is finding the correct strategy to use the code generator.
The documentation and scripts in the package say to call Sourcery like this:
"$sourcery" --xcode-project "${PROJECT_FILE_PATH}" --xcode-target "${TARGETNAME}" $MODULENAME1 $MODULENAME2 $#
In my case, the entities are present in my Package, so inside a directory, it would be correct if I use the Sourcery based ObjectBox code generator indicating the path "source" and the "output" instead of the project "--xcode-project " and of the "target"?
If this is not the correct way to go, do you have alternative ideas?
Related
Is there a way to control the Bazel build to generate wanted temp files for a list of source files instead of just using the command line option "--save_temps"?
One way is using a cc_binary, and add "-E" option in the "copts", but the obj file name will always have a ".o". This kind of ".o" files will be overwriten by the other build targets. I don't know how to control the compiler output file name in Bazel.
Any better ideas?
cc_library has an output group with the static library, which you can then extract. Something like this:
filegroup(
name = "extract_archive",
srcs = [":some_cc_library"],
output_group = "archive",
)
Many tools will accept the static archive instead of an object file. If the tool you're using does, then that's easy. If not, things get a bit more complicated.
Extracting the object file from the static archive is a bit trickier. You could use a genrule with the $(AR) Make variable, but that won't work with some C++ toolchains that require additional flags to configure architectures etc.
The better (but more complicated) answer is to follow the guidance in integrating with C++ rules. You can get the ar from the toolchain and the flags to use it in a custom rule, and then create an action to extract it. You could also access the OutputGroupInfo from the cc_library in the rule directly instead of using filegroup if you've already got a custom rule.
Thanks all for your suggestions.
Now I think I can solve this problem in two steps(Seems Bazel does not allow to combine two rules into one):
Step1, add a -E option like a normal cc_libary, we can call it a pp_library. It is easy.
Step2, in a new rules, its input is the target of pp_library, then in this rule find out the obj files(can be found via : action.outputs.to_list()) and copy them to the a new place via ctx.actions.run_shell() run_shell.
I take Bazel: copy multiple files to binary directory as a reference.
Can someone tell me how to get protoc to generate dart files with a leading library directive?
I'm using the dart-protoc-plugin (v0.10.2) to generate my dart, c++, c#, js and java models from proto files. I was under the impression there was no way to get protoc to add a 'library' directive to the generated dart files, until I noticed the directive appearing in another project (see date.pb.dart).
If I take the same file (date.proto) I cannot get protoc to generate a dart file containing a 'library' directive.
In short: I want to take a .proto file with the following content
syntax = "proto3";
package another.proj.nspace;
message MyObj {
...
}
and produce a .dart file with a leading 'library' directive similar to the following snippet
///
// Generated code. Do not modify.
///
// ignore_for_file: non_constant_identifier_names,library_prefixes
library another.proj.nspace;
...
NOTE: I don't care about the actual value of the directive since I can restructure my code to get the desired result. I just need a way for protoc to add the library directive...
The basic command I'm using to generate the dart files is
protoc --proto_path=./ --dart_out="./" ./another/proj/nspace/date.proto
Unfortunately the dart-protoc-plugin's README isn't very helpful and I had to go through the source to find out which options are available; and currently it seems like the only dart-specific option is related to grpc.
I've tried options from the other languages (e.g. 'library', and 'basepath') without any success.
It would simplify my workflow quite a bit if this is possible, but I'm starting to get the impression that the library directive in date.pb.dart is added after the code was generated...
After asking around a little bit, it seems that the library directive was removed from the protoc plugin at some stage (see pull request), thus it is no longer supported.
I've got a library written in Vala that has always worked fine generating a .vapi file for itself, I think because it's a free operation with valac but I'm not positive on that. I went and tried to use VAPIGEN_CHECK in my configure.ac file and the associated VAPIGEN_MAKEFILE in my Makefile.am and now I get:
error: The type name `GLib.TypeInstance' could not be found
My corresponding .gir file contains:
<field name="parent_instance">
<type name="GObject.TypeInstance" c:type="GTypeInstance"/>
</field>
So the error seems to make sense because I can't find the GObject.TypeInstance class/struct in any .vapi file, but GTypeInstance is in one of the GLib headers.
Should I even be doing it this way if I'm writing everything in Vala already? Is there a possibility that this is missing from the Vapi?
Edit: Possibly just due to my not deriving GLib.Object which I thought was implicit. Still trying to fix something else that prevents this but once that's done I will update this to say whether or not it actually matters.
To generate a VAPI file from a Vala program you should simply use the --vapi option with valac, e.g.:
valac --vapi my_library_name.vapi my_library.vala
From what you are describing I think you are generating a GIR (GObject Introspection Repository) file with valac, then using vapigen to create the VAPI file. vapigen is part of Vala and maintained in the Vala source code, but it is a tool for generating a VAPI file to bind to non-Vala projects. If the non-Vala project distributes a GIR file it makes the binding very easy.
When using vapigen you need to give the packages it uses, so you need to check you are including the right pkg-config flags, e.g.:
vapigen --pkg glib-2.0 --pkg gobject-2.0 my_library.gir
The other possibility is there is no binding for GTypeInstance in Vala. I've had a quick look and I'm not finding anything.
I managed to add a relative path dependency in my app
name: myapp
description: A sample app
dependencies:
mylib:
path: ../mylib
and then import it in my source code
import 'package:mylib/mylib.dart';
However, the name 'mylib' is taken from the library package pubspec and if I want to change it (for example 'mynewlib'), I have to change the name everywhere (pubspec AND dart source code)
It also prevent having 2 packages with the same name (yes I know, weird, but I don't control what people put in pub.dartlang.org). What I'd like to do is something like
name: myapp
description: A sample app
dependencies:
mylib:
path: ../mylib
name: mynewlib
and have in source code
import 'package:mynewlib/mylib.dart';
However I cannot find the proper syntax and whether that's possible or not. (Sample code ready for testing is here: https://github.com/alextekartik/dart-test/tree/master/lib_test). To note that here I'm not talking about library name but package name (and naming the package mylib can be confusing)
There is no way to define another name for a package itself (as far as I know - if there is, I'd be interested too).
However, as a workaround, you could rewrap it. For example, let's assume you have two "mylib" packages.
Create a new library application "mylib1". There, you import the first "mylib" and reexport it using export. Create another library application "mylib2" for the other "mylib". Then you have different package names to use in the same application.
Yes, it is kinda awkward, but as long as there is no better way...
You can resolve name conflicts at import with:
import 'package:mylib/mylib.dart' as Foo;
This will create a top level name to access the library API:
Foo.bar();
I want to let perl use the DBI module in my own path(suppose, /home/users/zdd/perl5/lib/DBI), but the sysem also has a DBI module which is /usr/lib/perl5/lib/DBI.
when I write the following code in my script, perl use the system path be default, how to force it use the one under my path?
use lib './perl5/lib/DBI';
use DBI;
sub test {
....
}
/usr/lib/perl5/lib/DBI was added to the PATH environment variable in my bash profile, it was used by many scripts, so I can't disable it.
The file for the main DBI module is in ./perl5/lib. So your path is not pointing to it.
The DBI folder contains sub-modules of DBI, e.g. DBI::Foo (the :: in module names is a representation of your module directory structure).
Try using ./perl5/lib as your library instead.
Also, using a relative path will fail if the current directory is not what you think it is. If you are in doubt, have your script call cwd to see what the current directory is.
For debugging purposes, it may be helpful to use:
no lib '[main Perl module library path here]';
That way you can be sure you are only using your custom module path. Any failure to find a module will cause an error, rather than silently using the system version.
Update: For more information, see Perldoc on use lib. Perl will use the library that you have specified first. If it does not, that indicates it is not actually finding the module in the location you have given.
In addition to what dan1111 suggested, I would also recommend you print out #INC (just before your use DBI statement) and dump %INC (just after your use DBI statement) to see what your script is doing. That may help you debug the issue.