I’ve tried to add a package to Buildroot that uses Qt and Boost. The package uses qmake to generate a Makefile, this part seems to be working, however I get an error when I build saying:
Could not find qmake configuration file qws/linux-arm-g++.
Error processing project file: MsgDisplay.pro
The contents of my package is laid out like this:
DummyPgm
├── main.cpp
├── MsgDisplay.pri
├── MsgDisplay.pro
├── MsgDisplay.pro.user
├── MsgHandler.cpp
├── MsgHandler.h
├── MsgServer.cpp
├── MsgServer.h
├── Tcp
│ ├── TcpAddrPort.cpp
│ ├── TcpAddrPort.h
│ ├── TcpServer.cpp
│ ├── TcpServer.h
│ ├── TcpSocket.cpp
│ └── TcpSocket.h
└── Tools
├── Banner.cpp
├── Banner.h
├── IoExt.h
├── SeparateArgumentList.cpp
├── SeparateArgumentList.h
└── SysTypes.h
2 directories, 20 files
I have added a package directory, dummypgm, which contains Config.in and dummypgm.mk files. The contents of the files are:
Config.in:
config BR2_PACKAGE_DUMMYPGM
bool "dummypgm"
help
Foo Software.
http://www.foo.com
dummypgm.mk:
DUMMYPGM_VERSION = 0.1.0
DUMMYPGM_SOURCE = DummyPgm-$(DUMMYPGM_VERSION).tar.gz
define DUMMYPGM_CONFIGURE_CMDS
(cd $(#D); $(QT_QMAKE) MsgDisplay.pro)
endef
define DUMMYPGM_BUILD_CMDS
$(MAKE) -C $(#D)
endef
$(eval $(generic-package))
Since the package is hosted locally, I’ve simply put the DummyPgm-0.1.0.tar.gz in the dl directory.
I’ve also added the following to package/Config.in:
source "package/dummypgm/Config.in"
I’m a little lost as to why this doesn’t work, if anyone could help me I would be very grateful. Also, is there any way to call $(eval $(qmake-package)) or something?
Are you using Qt4 or Qt5 ? Your package/dummypgm/Config.in should have a depends on on one of them, and your dummypgm.mk should have a DUMMYPGM_DEPENDENCIES = qt or DUMMYPGM_DEPENDENCIES = qt5base.
My intuition is that you are using Qt5. In this case, you shouldn't call $(QT_QMAKE), but $(QT5_QMAKE).
Have a look at http://git.buildroot.net/buildroot/tree/package/qextserialport/qextserialport.mk for an example. Note that this example supports both Qt4 and Qt5, probably in your case you only need one of the two.
Also, you should really subscribe to the Buildroot mailing list, you would get a lot more answers than here.
Related
I have 2 grpc services (service1 and service2) that interact with each other and on some cases the rpc response of service1 will consists of a struct defined in service2, after going to several situations where duplication is inevitable, i figure that as the services grow these will be hard to manage, so i restructure the proto files into something like this for now
.
├── app
...
├── proto
│ ├── service1
│ │ ├── service1.access.proto
│ │ ├── service1.proto
│ ├── service2
│ │ ├── service2.access.proto
│ │ └── service2.proto
│ └── model
│ ├── model.service1.proto
│ └── model.service2.proto
└── proto-gen // the protoc generated files
├── service1
│ ├── service1.access.pb.go
│ └── service1.pb.go
├── service2
│ ├── service2.access.pb.go
│ └── service2.pb.go
└── model
├── model.service1.pb.go
└── model.service2.pb.go
service1 needs to import the model definition on model/model.service2.proto, so i am importing it like this
import "model/model.service2.proto";
option go_package = "proto-gen/service1";
and i generate the .pb.go files, using this protoc command
ls proto | awk '{print "protoc --proto_path=proto proto/"$1"/*.proto --go_out=plugins=grpc:."}' | sh
the command generates the .pb.go files just fine, but the code on service1.access.pb.go doesn't seem to import the model correctly, and i don't know if it related or not but when i run the app, it throws this error
cannot load model: malformed module path "model": missing dot in first path element
i spent a few hours now googling on how can i properly import another proto file, i can't seem to find any solution
The reason you got that error about model is because the generated files use the go_package of the imported file, and model is not a valid import path. You have to convince the generated file to use the full import path of the package.
This is how I did it for my source tree: I have a similar tree of proto files importing each other. If your module is named, say github.com/myapp, then run protoc with --proto-path=<directory containing github.com>, import other proto files using full path, that is github.com/myapp/proto/service1/service1.proto, and in service1.proto, define go_package = service1. This setup writes the import paths correctly in my case.
Before settling into this solution, I was using go_package=<full path to proto>, so you might give that a try as well.
Building on Burak Serdar, I want to provide my implementation.
Set the package on the proto you want to import similar to this where the location is your full path. My path is generally github.com/AllenKaplan/[project]/[package]/proto/
option go_package = [path];
In the file you wish to import to add an import. My path is generally [package]/proto/[package].proto
import = [path from protoc proto path]
The last part is the protoc command where you must define the protopath in a way that connects the import path and option go_package path
if executing from the github.com/AllenKaplan/[project] directory, I would call
protoc -I. --go_out=./[package]/proto [package]/proto/[package].proto
-I. === --proto_path.
the -I. sets the protopath to the entire project
One note, when calling protoc on your .proto files that you are importing, you will want to add source_relative: to the output will ensure the output is from the root with a set package.
My implementation of the imported protoc when called from github.com/AllenKaplan/[project]/[package]
protoc -I./proto --go_out=paths=source_relative:./proto [package].proto
I was also facing a similar issue while importing. Had changed the .protoc file option package with the following.
option go_package = "./;proto-gen/service1";
The first param means relative path where the code you want to generate.
The path relative to the --go_out , you set in your command.
Here is my minimal example of below: https://www.dropbox.com/s/7fwsr3sigb60rtw/leveling-test.zip?dl=0
My current project folder structure and relevant CMakeLists content:
leveling
├── CMakeLists.txt: add_subdirectory(deps)
└── deps
├── CMakeLists.txt: add_subdirectory(xml-reading)
└── xml-reading
├── CMakeLists.txt: add_subdirectory(deps)
│ add_library(xml-reading ...)
│ target_include_directories(xml-reading PUBLIC ${CMAKE_CURRENT_LIST_DIR}/deps/tinyxml2)
│ target_link_libraries(xml-reading PUBLIC tinyxml2)
└── deps
├── CMakeLists.txt: add_subdirectory(tinyxml2)
└── tinyxml2
this generates a xml-reading.dll file.
But then the leveling project linker options have /DYNAMICBASE "bin\windows-32\debug\xml-reading.lib" "bin\windows-32\debug\BOBPrimitives.lib" "bin\windows-32\debug\tinyxml2d.lib"
Which yields:
2>LINK : fatal error LNK1104: cannot open file 'bin\windows-32\debug\xml-reading.lib'
What's up?
I tried adding SHARED to add_library(xml-reading SHARED ...), didn't help
As a workaround I set STATIC at add_library(xml-reading STATIC ...) to force it to produce a .lib file - but I'd like to understand what's going on
I'm new to go modules, and am taking them for a spin in a new project which I'm trying to model after the structure described here
Here is an example of my directory structure:
.
├── cmd
│ └── app_name
│ └── main.go
├── go.mod
├── go.sum
├── internal
│ └── bot
│ └── bot.go
└── pkg
├── website_name
│ ├── client.go
│ ├── client.options.go
│ ├── server.go
│ └── server.options.go
└── lib
└── lib.go
Is this idiomatically correct? I know there's not a whole lot of consensus out there, but I'd like to follow best practices.
When I run go build I get 'unexpected module path "github.com/ragurney/app_name/cmd/app_name"', but when I run go build ./... it works. Why?
When I move main.go to the top level everything works as expected. Should I just not use the /cmd pattern with modules?
To answer your first question, its completely opinionated and whatever you like best that is also easy to understand for others you should go with (I think it's fine).
To answer your second question the reason go build ./... works as opposed to go build from the root directory is because ./... starts in the current directory (the root) and searches for all program entry-points and builds them. When you move main.go to the root directory, with this new information, go build working then makes sense, as its only looking in the current directory.
You can explicitly say go build ./cmd/app_name which would also work.
Your application structure works perfectly fine with modules, as I use something very similar to it (https://www.ardanlabs.com/blog/2017/02/package-oriented-design.html) and modules work very well for me.
from what i can tell there is nothing wrong with your project structure. What has worked for me is to run the go build/run command from the project root
eg.
go run github.com/username/project/cmd/somecommand
go build -o somebinary github.com/username/project/cmd/somecommand
I prefer to add the specific file to build, there are some projects with more than one executable
go build -o app ./cmd/server/main.go
my working tree is like this:
/opt/go/src/tb-to-composer/
├── apis
│ └── rtb.go
├── config.yaml
├── jsondef
│ └── structures.go
├── LICENSE.md
├── README.md
├── tb-to-composer
└── thingsToComposer.go
when I do go build inside /opt/go/src/tb-to-composer/ the build doesn't recompile rtb.go and structures.go even though there was changes in them. In order to achieve build I need to run go build -a every time I do a change to rtb.go or structures.go, is that the expected behavior from go build? How to I recompile only custom libs inside my package folder without recompile the whole /opt/go/src tree?
You can try the -i flag, or (this does not work, sorry) specify the files in the directories explicitly as arguments to go build, i.e. go build thingsToComposer.go apis/rtb.go jsondef/structures.go
I am building a backbone.js app on a Rails 3.1 back-end. I'm using CoffeeScript to write the backbone classes, and Jasmine (via jasmine-headless-webkit) for testing.
Given the following (partial) tree:
.
├── app
│ ├── assets
│ │ ├── javascripts
│ │ │ └── views
│ │ │ ├── avia_view.js.coffee
├── spec
│ ├── javascripts
│ │ └── views
│ │ └── avia_view_spec.js.coffee
... I would expect avia_view_spec.js.coffee to know about Avia.AviaView, which is defined in avia_view.js.coffee.
However, I get the following output from running bundle exec jasmine-headless-webkit:
Running Jasmine specs...
F
Avia.AviaView render creates a new MatricesView . (/home/duncan/avia/spec/javascripts/views/avia_view_spec.js.coffee:10)
ReferenceError: Can't find variable: Avia in /home/duncan/avia/spec/javascripts/views/avia_view_spec.js.coffee (line ~5)
ReferenceError: Can't find variable: Avia in /home/duncan/avia/spec/javascripts/views/avia_view_spec.js.coffee (line ~10)
My jasmine.yml contains the following:
src_files:
- public/javascripts/prototype.js
- public/javascripts/effects.js
- public/javascripts/controls.js
- public/javascripts/dragdrop.js
- public/javascripts/application.js
- public/javascripts/**/*.js
I think I need to tell Jasmine to load the contents of avia_view.js.coffee but I'm not entirely sure how. Adding an explicit reference in the src_files section in jasmine.yml doesn't seem to make a difference ...
Could someone please tell me what I'm doing wrong here? I suspect it's something simple ...
Without having seen to much of your code, I'd suspect it beacuse of CoffeeScript's function wrapping (docs). You need to ensure that all the symbols you want to use are exported to somewhere you can get at them (here is a thorough discussion about that).
Edit: here's another longish and theoretical but good documentation on this topic.
Try adding this to your avia_view.js.coffee
(exports ? this).Avia = Avia
See this for a detailed explanation.
Alternatively try this;
window.Avia = Avia
We encountered the same problem; I highly recommend JasmineRice