I tried to enable ngx_stream_core_module by adding following code in nginx.inc
do_configure () {
--with-stream=dynamic
}
FILES_${PN} += "${PN}/*"
SYSROOT_DIRS += "${PN}/"
but compiling error happens,
nginx: Files/directories were installed but not shipped in any package:
/usr/modules/ngx_stream_module.so
and I am sure ngx_stream_module.so is generated in nginx/1.12.2-r0/package/usr/modules/.
Can anyone give me some ideas?
In FILES_${PN} you should reference the installation path of the installed files and the files themselves (the latter can be substituted by a wildcard) within a package. As follows:
FILES_${PN} += "/usr/modules/*"
Check out https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-FILES
Furthermore, you should point out to the YP version you're using, as well as the meta-layer that contains your nginx recipe.
PD: It is a bad practice to modify the *.inc or the *.bb of a recipe from a third party layer, write a *.bbappend on your own layer instead.
I've switched versions of QT (from 5.10.1 to 5.12.2) to get a more recent version of Mingw32 (from GCC/G++ 5.3 -> 7.3). The reasoning behind this is that have multiple products using the same library and using an old version of gcc is less than ideal. We've never had any issues with build before, but now I get the following error:
":-1: error: No rule to make target 'res/resources.qrc', needed by 'release/qrc_resources.cpp'. Stop."
Oddly enough, it does not stop the build from generating a completely functioning executable.
So far I've tried:
Cleaning the directory and building again
Deleting the build directory and building again
Not selecting shadow build option
Forcing Qmake (Build -> Run Qmake)
Creating a new .pro.user file
Deleting the whole repo, cloning it again, rebuilding the dependencies (we have a library which it relies on) and rebuilding QT
Adding the .qrc file to the includes (I know this was silly, but I was at my wits end)
Checking for deleted files (None that I can see)
Checking file names for inconsistencies(They seem ok)
Here is my qrc file
<RCC>
<qresource prefix="/">
<file>images/cnctbtn_connected.png</file>
<file>images/cnctbtn_connecting.png</file>
<file>images/cnctbtn_disconnected.png</file>
<file>images/configbtn.png</file>
<file>images/flash.png</file>
<file>images/logbtn.png</file>
<file>images/streambtn_start.png</file>
<file>images/streambtn_stop.png</file>
<file>images/d_logo_outlined.ico</file>
<file>images/d_logo_small.png</file>
<file>images/d_logo_small_outlined.png</file>
</qresource>
</RCC>
The list of resources which are located in the images folder
cnctbtn_connected.png
cnctbtn_connecting.png
cnctbtn_disconnected.png
configbtn.png
d_logo_small.png
d_logo_small_outlined.png
flash.png
logbtn.png
streambtn_start.png
streambtn_stop.png
d_logo_outlined.ico
The qrc_resource_File.cpp also looks ok. I see the bytes of the images in it, their names and assorted namespace declarations and functions in that name space.
The one thing I'm unsure of is why the images folder has it's on name in the resource name list.
Note: I've removed the bytes in this array, for my eyes and yours.
static const unsigned char qt_resource_name[] = {
// images
// cnctbtn_disconnected.png
// cnctbtn_connected.png
// cnctbtn_connecting.png
// streambtn_start.png
// d_logo_outlined.ico
// d_logo_small.png
// streambtn_stop.png
// d_logo_small_outlined.png
};
Ideally there would be no build error, which I don't really understand since I can see and use the executable produced. If you need any other information, don't hesitate to ask!
There is sbt project declaration
lazy val myProject = (Project("myProject", file("someRoot"))
enablePlugins ...
settings (...)
It has taskKey that extracts some dependencies to file system.
My problem is that for the moment of loading SBT I can't determine all the dependencies, it could be done only after private Command Alias is executed
addCommandAlias("resolveDependencies", "; resolveDependenciesTask; TODO: update myProject dependencies and reload it")
Is there anyway to do that?
Actually, disregard my comment on your question. You can use a command to modify the state of the build, so after you run it, the changes it made stay.
Something along these lines:
// in your build.sbt
commands += Command.command("yourCustomCommand")(state =>
Project.extract(state).append(
Seq(libraryDependencies += // settings you want to modify
"com.lihaoyi" % "ammonite-repl" % "0.5.7" cross CrossVersion.full),
state))
Then call it with sbt yourCustomCommand.
The state instance you return from the command becomes the new state of the build, i.e. if you've added some dependencies, the build will see them.
So I have a Q_OBJECT tagged class, which requires pregenerated .moc to be usable.
In my .qbs file, I have a CppApplication item; this seems to be the wrong type of project, as qbs does not call moc ClassName.cpp to generate moc's for me. What should be used instead/tweaked?
-
So I knew about Qt.core dependency, but it wasn't working on my crippled install of Qt; while I was trying to fix it, these facts came up:
It was required to detect Qt toolchain (qbs-setup-qt) and call qbs-config-ui
Qbs indeed stores the build rules in core.qbs, linked in via Qt/core dependency.
it's possible to copy/paste the build rules into my own .qbs file and avoid external dependencies; I'm considering this as a dirty hack for deploying the code on really crippled build systems (now I have a word for Qt support on Gentoo).
I think you might be missing the dependency of the application on the Qt-modules.
The rule for generation of the moc files is part of the Qt.core module.
You might add this dependency with:
CppApplication {
name: "MyApp"
files: "path_to_source/**"
Depends { name: "Qt.core" } // Optional
Depends { name: "Qt.widgets" }
}
As all other Qt modules have an implicit dependency on Qt.core the explicit dependency could on Qt.core could be skipped if there is a dependency on a different Qt-module (Qt.widgets in this example).
More details could be found at http://doc.qt.io/qbs/qt-modules.html
Sorry for another 'phpunit doesn't work' question. It used to work for years now. Today I reinstalled PEAR and phpunit for reasons not connected to this problem. Now when I run phpunit as I usually did. Nothing happens. The cli just shows me a new line, no output whatsoever.
Has anyone encountered this problem or has an idea what could have caused it.
PHPUnit Version: 3.5.15
PEAR Version: 1.9.4
PHP Version: 5.3.8
Windows 7
I'm on OSX and MAMP. To get error messages I had to adjust the following entries in php.ini:
display_errors = On
display_startup_errors = On
Please not that this has to go into /Applications/MAMP/bin/php/php5.3.6/conf/php.ini .
For future reference, for those who are facing any problem with PHPUnit, and PHPUnit is failing silently, just add this three lines inside phpunit.xml:
<phpunit ....... >
...
...
<php>
<ini name="display_errors" value="true"/>
</php>
</phpunit>
After that run the tests again, and now you can see why PHPUnit is failing,
AND ... ENJOY UNIT TESTING :)
I know the orignal poster's question is already answered, but just for any people searching in the future: one thing that can cause PHPUnit to fail silently (i.e. it just stops running tests without telling you why) is that it has an error handler that it set up before each test run, which is intended to capture errors and display them at the end of the test run. The problem is that certain errors halt execution of the whole test run.
What I generally do when this happens, as a first step, is reset the error handler to something that will immediately output the error message. In my base test class I have a method called setVerboseErrorHandler, which I'll call at the top of the test (or in setUp) when this happens. The below requires php 5.3 or higher (due to the closure), so if you're on 5.2 or lower you can make it a regular function.
protected function setVerboseErrorHandler()
{
$handler = function($errorNumber, $errorString, $errorFile, $errorLine) {
echo "
ERROR INFO
Message: $errorString
File: $errorFile
Line: $errorLine
";
};
set_error_handler($handler);
}
Create the simplest test class you can without a bootstrap.php or phpunit.xml to first verify that your new installation works. PHPUnit will stop without any message if it cannot instantiate all of the test cases--one for each test method and data provider--before running any tests.
You have already figured out how to get it to work, but my solution was a little different.
First thing you can do is check the exit status. If it's not 0, then PHP exited and because of the INI configuration settings set, none of the PHP error messages were outputted. What I did was to enable the "display_errors" INI setting, and set "error_reporting" to E_ALL. I was then able to identify errors such as PHP not being able to parse a certain script. Once I fixed that, PHPUnit ran properly.
I managed to spectacularly paint myself in a corner with a custom "fatal error handler" that in certain rare conditions turned out to output nothing. Those conditions, in accordance with Murphy's Law, materialized once I had forgotten the handler was in place.
Since it wasn't really a "PHPunit problem", none of the other answers helped [although #David's problem was at the bottom the same thing], even though the symptoms were the same - phpunit terminating with no output, no errors, no log and no clue.
In the end I had to resort to a step-by-step tracing of the whole test suite by adding this in the bootstrap code:
register_shutdown_function(function() {
foreach ($GLOBALS['lastStack'] as $i => $frame) {
print "{$i}. {$frame['file']} +{$frame['line']} in function {$frame['function']}\n";
}
});
register_tick_function(function() {
$GLOBALS['lastStack'] = debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS, 8);
});
declare(ticks=1);
If anyone ever manages to do worse than this, and somehow block stdout as well, this modification should work:
register_shutdown_function(function() {
$fp = fopen("/tmp/path-to-debugfile.txt", "w");
foreach ($GLOBALS['lastStack'] as $i => $frame) {
fwrite($fp, "{$i}. {$frame['file']} +{$frame['line']} in function {$frame['function']}\n");
}
fclose($fp);
});
an old thread this one, but one I stumbled across when having the same problem.
I had the same problem, nothing being returned to console including print, print_r, echo etc.
solved it by using --stderr as a test-runner option.
Check that you haven't written any logic into your code that just dies, with no output. For example,
<?php
if (!array_key_exists('SERVER_NAME', $_SERVER)) {
die();
}
This was exactly my case; I'd made some assumptions about the environment which were correct when running the code via Apache, but weren't fulfilled when running from CLI and the code did not echo any output.
PHPUnit tried to include the bootstrap file before giving the usual init output, but died during the bootstrapping proccess, hence exiting with status 0 and no output.
If when you run from command line a recent version of phpunit like this
> php phpunit
or
> ./phpunit
or
> php ./phpunit.phar
or
> ./phpunit.phar
And you immediatly return to the prompt with no messages, this is probably due to a "suhosin secutiry" setup.
phpunit is now a "phar" package including all libraries. To be able to run such file when php has the suhosin security module enabled, you must first set this
suhosin.executor.include.whitelist = phar
into you php.ini file (for example, with debian/ubuntu, you may have to edit file /etc/php5/conf.d/suhosin.ini
i tried everything here, but nothing worked until i tried phpunit --no-configuration simpletest.php. that finally gave me some output, which implies that my phpunit.xml.dist file is broken. (i'll come back and update this once i debug it.)
the contents of simpletest.php are below, but any test file should work.
<?php
use PHPUnit\Framework\TestCase;
final class FooTest extends TestCase
{
public function testFoo()
{
$this->assertEquals('x', 'y');
}
}
Check if the phpunit you're running and the one you installed are the same:
$ pear list phpunit/phpunit
...
script /path/to/phpunit
...
Try to execute exactly that phpunit with the full path.
Then check your PATH variable and see if the correct directory is in it. If not, fix that.
If that does not help, use write something into the phpunit executable, e.g. "echo 123;" and run phpunit. Check if you see that.
For me the conflict was with Xdebug's directive
xdebug.remote_enable=1
If you are using composer, check to make sure your included PHP files are not ending the code executions. The same goes for when you included certain PHP files explicitly.
In my case, I was working on a WordPress plugin and one of the PHP files I included directly in composer.json (which I don't want to load through PSR-4 because WordPress's coding standards don't support it yet) had this code on top;
if (!defined('ABSPATH')) {
exit(); // exit if accessed directly
}
And since ABSPATH will not be defined when I run the tests directly, the code was exiting.
This is because, since I told Composer to always load these files each time, this part of the code will execute, while the other files included though autoload PSR will load on demand.
So check to make sure any of the files you included are not stopping the code execution. If it happens, then even when you run phpunit --info the code will still exit and you won't see any output.
I was facing a seems problem. I could run phpunit from root directory but not from anywhere else. so I put the "--configuration" tag, and point it to my xml configuration.
$ ./<path_to_phpunit>phpunit --configuration <path_to_phpunitxml>/phpunit.xml
The path to phpunit is optinal, I used it because I installed locally by composer.
In /composer/vendor/phpunit/phpunit/src/TextUI/Command.php in main() function in catch (Throwable $t) {} block var_dump (echo / print_r) exception. If an exception exists, you, probably, will solve the current problem.