I am depending on a few artifacts that I need to both compile and run my application.
According to the Gradle docs, the runtime configuration extends the compile configuration, so surely adding a dependency using runtime implies an implicit compile dependency?
At least that was my assumption, but it does not work. When just depending on the artifact using runtime, my project does not compile anymore. I literally have to:
compile 'oauth.signpost:signpost-core:1.2.1.2'
runtime 'oauth.signpost:signpost-core:1.2.1.2'
for the application to both compile and see the Signpost classes at runtime.
Am I missing something? That just doesn't look right...
Almost right. Runtime configuration, indeed, extends compile configuration (docs). It means, that any dependency added to compile configuration is available in runtime configuration (docs).
compile 'oauth.signpost:signpost-core:1.2.1.2' will be enough to get this artifact in both, runtime and compile.
Related
I've started a CUDA application in the new CLion 2020.1 version. Although I can compile and run it, I am not able to debug it, not even the host code. Specifically, debug does not stop at breakpoints, even though I am running the debug build. I'm not encountering this issue with running a regular C project in CLion 2020.1. I don't receive any error message of any kind. Here is my CMakeLists.txt file:
# Setup the CUDA compiler
set(CMAKE_CUDA_COMPILER /usr/local/cuda-10.2/bin/nvcc)
# Setup the host compiler
set(CMAKE_CUDA_HOST_COMPILER /usr/bin/g++-8)
# CMAKE minimum required version
cmake_minimum_required(VERSION 3.16)
project(PageRank_GPU CUDA)
set(CMAKE_CUDA_STANDARD 14)
add_executable(PageRank_GPU main.cu graph.cu graph.cuh vertex.cuh error.cuh parser.cu parser.cuh)
set_target_properties(
PageRank_GPU
PROPERTIES
CUDA_SEPARABLE_COMPILATION ON)
Reporting that the issue has disappeared after playing around in the project settings a bit. Specifically, under Build, Execution, Deployment then Toolchain, I set the C and C++ compilers to gcc-8 and g++-8 respectively (even though I am specifying the compiler in the CMakeLists.txt file) and under CMake, I set the toolchain to "Default" (the one I just modified) instead of "Use Default". After doing that, the debugger stops at breakpoints and I am able to step through my code. I don't understand what happened because, even after reverting the changes, I cannot make the problem re-appear.
I'm trying to compile the mysqlclient.lib library as a Multithreaded Debug DLL. I need it in this configuration to be able to link it to my project. To give some context I will explain what have I done so far:
I cloned the MySQL repository: git clone https://github.com/mysql/mysql-server.git
I created the MySQL.sln by running CMake.
I opened the solution in Visual Studio 2013 and built it with the Runtime Library setting equal to /MDd.
I have tried to link the thus compiled library mysqlclient.lib to my project(which is compiled with /MDd) but I'm still getting the error:
mysqlclient.lib(plugin_client.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in main.obj
I have run dumpbin /all mysqlclient.lib | find /i "mvscr" obtaining as a result /DEFAULTLIB:MSVCRTD which suggests that the library has been compiled as /MDd.
I have to admit that before wanting to link mysqlclient.lib to my project I was not even aware of the Runtime Library setting. At this point I don't completely understand why I'm getting the linker error above, which is why I wrote in the title that I think that the library is still getting compiled as /MTd. If anyone could point me to the right direction in order to solve my problem it would be very much appreciated.
EDIT
Reading better the MySQL documentation I found out that if my project is built as /MDd or /MD I have to link it to the libmysql.dll dynamic library. Section Compiling MySQL Clients on Microsoft Windows, second to last paragraph.
https://dev.mysql.com/doc/refman/5.6/en/c-api-building-clients.html
I already know the coding part of actionscript worker. Recently I switched my IDE to FlashDevelop. I can't figure out how to compile actionscript worker swf in FlashDevelop.
I try to use Tools - Flash Tools - Build current file. But it throws error saying
Error: Type was not found or was not a compile-time constant: File.
Maybe it is because my project is a AIR project and I use AIR API in my worker.
I also try to compile worker swf using amxmlc via command line. It compiles successfully. But AIR Debug Launcher crashes when executing worker swf part. The swf which I compiled manually is nearly half size of the former one that Flash Builder generated for me. I guess I compiled a release version swf so that ADL can't debug and then crashed.
So how do I compile a worker swf in FlashDevelop to debug or to publish a release of project?
Update:
I find that the "Build current file" command in menu is a feature in FlashDevelop called quick build. By default, it will compile current file output to project root directory without arguments. We can add compiler arguments using #mxmlc ASDoc tag (see the links below for detail) to make it compile a worker swf for us. But currently in FD 5.0.1 it seems to be a bug that #mxmlc +configname=air doesn't compile air swfs. I find a workaround using #mxmlc -noplay -library-path=[Flex_SDK]\frameworks\libs\air\airglobal.swc -library-path=[Flex_SDK]\frameworks\libs\air\airframework.swc, but the path can't be surrounded with quote otherwise FD will show an error. I may look into the source and try to fix it.
links:
AS3 Quick Build documentation
Quick Build
FlashDevelop: Compiling Multiple SWF In One Project
Compiling a worker is no different from compiling any swf, you will need a separate project to compile the worker, unless your main worker loads itself as a worker.
Since FlashDevelop does not manage dependencies beetween projects, you will have to compile it manually, then the main worker.
You may automate it with make or any build system outside FlashDevelop, or use Pre/Post build command lines
By the way amxmlc is just a shortcut for 'mxmlc +configname=air', -debug=true will compile debug version
I can assure you that File can be used in a worker, basically it's just some actionscript bytecode loading some other actionscript bytecode and having it run in a separate thread, so any swf can be used as a worker, except if it doesn't use flash.system.Worker class, it won't be able to communicate with other workers, or to stop itself.
To sum up, the limitations and issues are rather about communicating beetween threads and synchronizing them. For instance, being able to only copy complex objects through AMF3 serialization,pass only basic types/objects as parameters will makes it impossible to interact with the display list from non-main workers
Dont forget to update FlashDevelop /AIR SDK for best workers support
My question is a little bit common, but it is linked with Gradle too.
Why we need compile and runtime configuration?
When I compile something I need artifacts to convert my java classes in bytecode so I need compile configuration, but why is needed runtime configuration do I need something else to run my application in JVM?
Sorry if it sounds stupid, but I don't understand.
In the most common case, the artifacts needed at compile time are a subset of those needed at runtime. For example, let's say that a program called app uses library foo, and library foo internally uses library bar. Then only foo is needed to compile app, but both foo and bar are needed to run it. This is why by default, everything that you put on Gradle's compile configuration is also visible on its runtime configuration, but the opposite isn't true.
Updating the answer as per the latest gradle versions.
From gradle's official documentation at below link:
https://docs.gradle.org/current/userguide/upgrading_version_5.html
Deprecations
Dependencies should no longer be declared using the compile and runtime configurations The usage of the compile and runtime
configurations in the Java ecosystem plugins has been discouraged
since Gradle 3.4.
The implementation, api, compileOnly and runtimeOnly configurations should be used to declare dependencies and the compileClasspath and
runtimeClasspath configurations to resolve dependencies.
More so, the compile dependency configuration has been removed in the recently released Gradle 7.0 version.
If you try to use compile in your Gradle 3.4+ project you’ll get a warning like this:
Deprecated Gradle features were used in this build, making it
incompatible with Gradle 7.0. Use ‘–warning-mode all’ to show the
individual deprecation warnings.
You should always use implementation rather than compile for dependencies, and use runtimeOnly instead of runtime.
What is an implementation dependency?
When you’re building and running a Java project there are two classpaths involved:
Compile classpath – Those dependencies which are required for the JDK to be able to compile Java code into .class files.
Runtime classpath – Those dependencies which are required to actually run the compiled Java code.
When we’re configuring Gradle dependencies all we’re really doing is configuring which dependencies should appear on which classpath. Given there are only two classpaths, it makes sense that we have three options to declare our dependencies.
compileOnly – put the dependency on the compile classpath only.
runtimeOnly – put the dependency on the runtime classpath only.
implementation – put the dependency on both classpaths.
Use the implementation dependency configuration if you need the dependency to be on both the compile and runtime classpaths. If not,
consider compileOnly or runtimeOnly.
I'm getting this error while trying to run sample codes in CUDA SDK. I have CUDA 2.3 and Visual studio 2008
LINK : fatal error LNK1181: cannot open input file 'cutil32D.lib'
Any pointers how to solve this?
Since you're compiling the SDK samples, the project files are probably correct. Far more likely is that you haven't built the cutil library. Go to the SDK install directory, then into the "C" directory. You'll see a "common" directory, in there open the cutil.sln solution (or cutil_vc90.sln for VS2008) and build it in release and debug modes for your platform.
Then try your sample again.
The cutil library is used to avoid replicating the same code through all the samples, if you're starting your own project I'd avoid reusing the cutil library and write your own checker. For example, you should probably fail gracefully if you detect a CUDA error rather than just calling exit() as done in cutil.
The cuda.rules file included in the SDK is highly recommended! Using this you can just add .cu files to any project and Visual Studio will know how to compile them and link them in to the final executable. Easy!
Your MSVC project needs to include the library cutil32D.lib to link. Once you specify it as a library the linker needs to include in the final binary artifact this problem will go away. It would seem the library is missing at the location the linker is going to look for it. You'll have to change the library search paths or move that file to a directory in which the linker is already looking.
I ran into the same issue. It turned out not only did I need to build the cutil project but also the shrUtils project under the SDK's shared folder.