How can I make an sbt plugin whose build definition has a dependency on code written in the plugin itself?
Because sbt is recursive, this is simple. Create or edit project/build.sbt, and add
unmanagedSourceDirectories in Compile += new File("src/main/scala")
the old answer no longer works.
Need a small tweak, add getAbsoluteFile at the end:
unmanagedSourceDirectories in Compile += file("src/main/scala").getAbsoluteFile
Related
after changing the sbt.version in the build.properties to 1.3.x, i've found out that the resolved.xml.xml files, which were created after running sbt compile are not created anymore. i'm using those files to re-create the project's structure and dependencies tree.
is there any equivalent to those files in the new SBT version?
yes, i'm familiar with sbt-dependency-graph plugin, but i want to avoid using external solution.
You can disable the integrated coursier to get the old behaviour back:
ThisBuild / useCoursier := false
I wrote a custom plugin for QCanBus, that simply is a copy of the socketcan plugin but has been renamed and the identifiers have been adjusted to that new name.
I did that copying to first get the plugin recognised before I alter it.
I changed the qmake project to look that way:
TEMPLATE = lib
TARGET = qtcopysocketcanbus
CONFIG += plugin
QT = core serialbus
HEADERS += \
copysocketcanbackend.h
SOURCES += \
main.cpp \
copysocketcanbackend.cpp
DISTFILES = plugin.json
and added the plugin.json like so:
{
"Key": "copysocketcan"
}
I then renamed everything else from socketcan to copysocketcan in the main.cpp, the copysocketcan.cpp and the copysocketcan.h as well.
When I build the project, I get my *.so file which i put into $QT_PLUGIN_PATH/canbus/ on my target.
However, a quick start reveals, that qt only lists the plugins that came with the installation, not my added custom one.
I tried putting QLoggingCategory::setFilterRules(QStringLiteral("qt.canbus* = true")); as first line in my code and hoped getting more debug output, but I only get the debug output that my own application is producing. No output from the actual QCanBus.
So my questions are
How to enable the debug output for qt.canbus? Do I have to build QT with debug config for that?
Does my approach for creating a plugin reasonable?
Any ideas, why the custom plugin is not listed?
Through a helpful comment, I was able to debug the problems. The commentor suggested to use QT_DEBUG_PLUGINS to debug the plugin call. That lead to the appearance of an error message, that clearly stated, that the plugin I was trying to load because it was not a plugin and plugin metadata could not be extracted.
A bit of googling after those messages helped.
The answer to question 1 is:
Yes, you apparently have QT to build with debug information, to get the actual log output.
In my case, I configured the framework with --force-debug-info
For the second question, my approach was indeed reasonable, because as answer for question 3 turned out that one has to include the moc file as soon, as a Q_OBJECT macro is used within a *.cpp file and not in a separate header, which is the case for the canbus plugins. You can read more about that here
I use SBT / Console as a prototyping tool and therefore don't want to start with a pre-defined build.sbt file.
What I want to do is to run the sbt tool and then modify the libraryDependencies setting. then run console and go and use my newly imported library. If I need something more. I can exit the console and import more stuff and then come back in the console.
is this possible? or should I always start with a predefined build.sbt file?
set libraryDependencies += group % art % version
I understand ammonite is good at this as well
I have a dependency (stagemonitor.org) that I want to include for everything except "test" and "test:test". How do I include a dependency for everything but "test"? I'm using SBT 0.13.8.
Thanks,
Johan
You likely need to exclude things manually via managedClasspath in Test.
Check out -= operator we are adding on 0.13.9-RC1.
What changes must I make to the .pro file if I want to execute chmod command, execute the output binary file, or do some other operations.
I had a similar problem. I wanted a special tool (versioner) to run over the code every time the Makefile was executed. Here's the solution:
(to be read in the Qmake Manual, Configuring qmake's Environment, Section: Customizing Makefile Output)
Create you own Makefile target. Specify the command etc.
mytarget.target = .buildfile
mytarget.commands = touch $$mytarget.target
QMAKE_EXTRA_TARGETS += mytarget
This way, you have an extra target you can call with make mytarget for example. If you want to tie it together to the actual buildtarget you'll have to add:
POST_TARGETDEPS += mytarget
Hope that helps.
Best regards
D
Another way to make things in given order is to use empty "super" target:
super.depends = target_pre first target_post
QMAKE_EXTRA_TARGETS += super
Where first - is default qmake target, and target_pre and target_post some custom targets. Now make super just do the thing.
EDIT: looks like in last versions of Qt build of dependencies is running in paralell so this solution wouldn't work.
If you are using Qt Creator, you can add custom build steps in the Projects panel: http://doc.qt.nokia.com/qtcreator-2.1/creator-build-settings.html#adding-custom-build-steps
The right answer depends on exactly what you want, and when. However, as seen in some previously posted comments here QMAKE_POST_LINK is probably what you want rather than POST_TARGETDEPS.
Check out this related post:
QMake: execute script after build
For one, when you use POST_TARGETDEPS that fires off BEFORE your exe is created (in Windows) or BEFORE it is recreated (in Linux)! QMake works differently depending upon the platform and the complier.
I needed to do some "symbols processing" on an exe when it was recompiled. POST_TARGETDEPS gave me problems in both Windows (using mingw) and Linux (using gcc). In Windows, it executed my script prematurely, and in Linux it overwrote my exe after I had modified it (i.e. added back my debugging info to the exe after I had stripped it in my external script). QMAKE_POST_LINK worked perfectly, however, in both cases. It's also short, sweet, and more clear by comparison!