I'm building an sbt project with these settings:
scalaVersion := "2.11.8",
crossScalaVersions := Seq("2.11.8", "2.12.8"),
When compiling, sbt copies resource files to the classes/ output folder.
However, the resource files for other scala versions than the current one get deleted somehow. That's unexpected, especially because the compiled .class files remain for both versions.
I tried to enable -v for verbose & -d for debug, but still can't see why/where the resources get deleted from the other version's classes/.
sbt +mleap-spark-extension/compile -d -v
[debug] Copy resource mappings:
[debug] (/Users/juhoautio/ideaprojects/mleap/mleap-spark-extension/src/main/resources/reference.conf,/Users/juhoautio/ideaprojects/mleap/mleap-spark-extension/target/scala-2.11/classes/reference.conf)
debug] Copy resource mappings:
[debug] (/Users/juhoautio/ideaprojects/mleap/mleap-spark-extension/src/main/resources/reference.conf,/Users/juhoautio/ideaprojects/mleap/mleap-spark-extension/target/scala-2.12/classes/reference.conf)
Then:
find mleap-spark-extension/target -name reference.conf
Finds only the last one, ie.:
mleap-spark-extension/target/scala-2.12/classes/reference.conf
However, both target/scala-2.12/classes/ and target/scala-2.11/classes/ still have the compiled .class files. It's just the resource file that gets lost.
Also if I only build with 2.11 after that:
sbt mleap-spark-extension/compile -d -v && find mleap-spark-extension/target -name reference.conf
Then:
find mleap-spark-extension/target -name reference.conf
Finds only the last one, ie.:
mleap-spark-extension/target/scala-2.11/classes/reference.conf
This is with sbt.version = 0.13.18. This might've changed in newer versions, but upgrading is not trivial, so I'm trying to at least find out why this happens with the current version.
How could I debug this further? Ideally I would want sbt to not touch the other scala version's classes/ folder at all!
Related
I am curious if you can control the output "src" folder in AWS CodeBuild.
Specifically, I see this when debugging the build in CodeBuild.
/codebuild/output/src473482839/src/github.....
I would love to be able to set/change/remove the src473482839 part of that path, because I have a feeling it is causing my sbt to recompile my scala source files, although I am using CodeBuilds new localcache to cache my target folders between builds, the compiled class's canonical path change between builds, which is what I suspect is causing the problem
After some more debugging I have managed to get my 6 minute builds down to 1:30s.
Although you are not able to set or override the CODEBUILD_SRC_DIR I have found a work around in my buildspec.
This is what my buildspec looks like now, with local caching enabled in codebuild.
version: 0.2
phases:
pre_build:
commands:
- mkdir -p /my/build/folder/
- cp -a ${CODEBUILD_SRC_DIR}/. /my/build/folder
build:
commands:
- cd /my/build/folder
- sbt compile test
cache:
paths:
- '/root/.ivy2/cache/**/*'
- '/root/.cache/**/*'
- 'target/**/*'
- 'any other target folders you may need'
The key change I had to make was copy over the source(cached target directories) in the pre_build phase, and change directory and compile from the new, static directory
I hope this helps someone else down the road until CodeBuild allows a person to set/override the CODEBUILD_SRC_DIR folder
Error-
$ qmake
qmake: could not find a Qt installation of ''
I installed Qt Version 4.8.2
Partial File of .profile in my home directory
# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
PATH="$HOME/bin:$PATH"
PATH="/usr/local/Trolltech/Qt-4.8.2/bin:$PATH"
PATH="/home/user/qt-everywhere-opensource-src-4.8.2/bin:$PATH"
export PATH
fi
Output-
$ which qmake
/usr/bin/qmake
Properties
Name - qmake
Type - Link to executable (application/x-executable)
Link Target - qtchooser
Location - /usr/bin
qmake is present in this location
/usr/local/Trolltech/Qt-4.8.2/bin
Properties
Name - qmake
Type - executable (application/x-executable)
Size - 3.4 MB (3,407,312 bytes)
Location - /usr/local/Trolltech/Qt-4.8.2/bin
qmake is also present in this location
/home/username/qt-everywhere-opensource-src-4.8.2/bin
Properties
Name - qmake
Type - executable (application/x-executable)
Size - 11.2 MB (11,157,974 bytes)
Location - /home/username/qt-everywhere-opensource-src-4.8.2/bin
How to make qmake work? Which one is the correct path for qmake?
This is really simple. You don't need to modify any environmental variables, you don't need to set up QTDIR. There are only two facts you need to keep in mind:
You must invoke qmake from your desired version of Qt.
There's a 1:1 relationship between a particular installed Qt version and build, and qmake executable.
After the desired qmake was run and generated the makefile, invoking make will build your project using the version of Qt the qmake came from. This will happen in spite of any environmental variable settings etc.
So, all you need to know is which Qt installation you want to use, and its path. This should be obvious since you installed Qt yourself. There lies the bin/qmake that you need.
You can select the desired qmake just as you would select a particular binary to run. The process is not any different just because it is qmake and not, say gzip:
by explicitly typing out the path to the executable,
by using a shell alias,
by putting the desired Qt's bin folder onto the PATH.
Only you know where you installed your desired version of Qt - there are at least three paths in your question. Thus it's impossible to tell which qmake are you to invoke. Obviously one of them - the one picked up by which qmake - doesn't work.
You need to invoke the one that came with the version of Qt that you installed.
That's really all there's to it.
I think the source code is in this location:
/home/user/qt-everywhere-opensource-src-4.8.2/bin
and installation directory is at:
/usr/local/Trolltech/Qt-4.8.2/bin
you need to add the installation directory to your PATH, however if you have an other version (like the one in /usr/bin) you need to use /usr/local/Trolltech/Qt-4.8.2/bin/qmake to compile Qt project using this version.
My solution is to add this code to your .profile file:
export QTDIR="/usr/local/Trolltech/Qt-4.8.2"
export PATH="$QTDIR/bin:$PATH"
alias qmake-4.8="$QTDIR/bin/qmake"
after that use qmake-4.8 instead of qmake
I've recently installed PHPUnit on a Mac (10.8.3) (running PHP 5.4.7). When I attempt to a run a test phpunit testfile.php for example, I receive:
Warning: require_once(File/Iterator/Autoload.php): failed to open stream: No such file or
directory in /Users/myusername/pear/share/pear/PHPUnit/Autoload.php on line 64
Fatal error: require_once(): Failed opening required 'File/Iterator/Autoload.php'
(include_path='.:') in /Users/myusername/pear/share/pear/PHPUnit/Autoload.php on line 64
The file, /Users/myusername/pear/share/pear/File/Iterator/Autoload.php exists.
php.ini correctly lists the pear directories in the include path:
.:/php/includes:/usr/local/apache/lib/php:/Users/myusername/pear/share/pear/
Yet when I var_dump(get_include_path()); inside of the PHPUnit/Autoload.php file, it prints .: as if it's empty.
Dumping the value of php_ini_loaded_file instead, simply returns false.
Using php -i |grep php\.ini and php --ini only show one php.ini being used/loaded:
Configuration File (php.ini) Path => /usr/local/apache/lib
Loaded Configuration File => /usr/local/apache/lib/php.ini
I repeated the var_dumps of the include_path and the loaded_ini_file from a simple test.php file I ran from the command line and they print out the correct info. So something involved with phpunit is not loading the right/any php.ini.
I'm not using any configurations that are different than default - phpunit was just installed on this machine today.
Make sure the php.ini file you are using is the one loaded for cli php. At least on my install of PHP on Linux, I have two php.ini files, one at /etc/php/cgi-php5.4/php.ini, and the other at /etc/php/cli-php5.4/php.ini. If you change the cgi version, it won't by default affect the cli version, and would cause the include path to be empty.
Another place to check is the phpunit.xml file. It has a section to specify the include path. See here for options available. I'm not sure why phpunit would reset the path but this might be a way to solve the issue.
The solution was:
After running
`pear config-get php_bin` -i | grep -E Configuration\ File\|include_path
It showed that Pear was using a different ini path than php-cli was:
Configuration File (php.ini) Path => /etc
Loaded Configuration File => (none)
include_path => .: => .:
Turns out, Pear had been configured by the original/default Mac OS copy of PHP, not by the custom version I had installed later on.
A quick fix that may not be best long-term was to symlink the ini file it was trying to find:
sudo ln -s /usr/local/apache/lib/php.ini /etc/php.ini
Afterwards, phpunit FakeTest commands are work, and the tests run.
Eventually I need to re-install/re-configure Pear to work with the version of php I've loaded.
In my project I have made configure.ac and Makefile.am files correctly so my components compile and dynamically link to the appropriate libraries. One of these components links to a library that uses QT, so the appropriate Makefile must be generated out of the .pro file prior compilation on the target system.
For this I think that I need to find a way to tell my make scripts, through Makefile.am perhaps, that this library must be compiled on its own by first running qmake and the generated Makefile in that directory.
Is this even possible? If so, how do I do it?
Researching on my own I have found an apparently abandoned project called “AutoTroll” which is supposed to automatically alter files of autotools in order to add compatibility with Qt4. I have tried to make it work with no luck. It lacks a proper documentation also.
Without this tool, compiling Qt4 modules with autotools requires a lot of hacking and interventions, making it really hard and even more for a cross-platform application.
I have switched to CMake. CMake’s setup is far easier than autotools’ and it supports Qt4 modules out of the box.
We do this, its not that difficult. In configure.ac:
QT_QMAKE
[
echo $QMAKE -o Makefile.myapp $(realpath $(dirname $0))/myapp.pro
$QMAKE -o Makefile.myapp $(realpath $(dirname $0))/myapp.pro
]
Then (Assuming your macros are located in the standard m4 directory), make a file called qt_qmake.m4 there.
AC_DEFUN([OTT_QT_QMAKE],[
if test -z "$QMAKE"; then
QMAKE=$(which qmake)
$QMAKE -v > /dev/null 2>&1
if test $? -ne 0; then
AC_MSG_ERROR([qmake executable not found!])
fi
fi
AC_SUBST(QMAKE)
])
Then in Makefile.am:
ACLOCAL_AMFLAGS=-Im4
all-am:
make -f Makefile.myapp all
install-am:
make -f Makefile.myapp install
qmake_all:
make -f Makefile.myapp qmake_all
clean-am:
make -f Makefile.myapp clean
That should align with the targets that QTCreator uses, and allows you to "bootstrap" qmake using autotools to make a config.h for instance, or global qmake include file to make shadow builds easier. Theres a lot I'm leaving out if you want to have version checking,etc... but it should get you started. If you built qt yourself, or have it not in your path, ie redhat (/usr/lib{64}/qt5/bin/qmake), you can just use the QMAKE variable to point to it. QT is smart enough with that to take it from there usually. I know its not the most elegant solution, but its worked for us cross-linux for almost a decade.
I have been using the --cvs-exclude option on my rsync scripts for a little over a year now. I work with an SVN repository so it keeps the SVN files out of production.
Today I attempted to rsync changes and suddenly rsync wasn't picking anything up from a folder named "core." Upon investigating I found out that "core" is a CVS folder so it gets ignored.
So my question is why rsync worked at all for me, but suddenly today decided to start ignoring the "core" folder like it should be.
I've solved the problem by simply ignoring SVN files instead of using CVS exclude, but am still perplexed as to why rsync worked for up until today.
My old rsync code:
rsync -vcaz --no-p --cvs-exclude --exclude downloader --exclude media --exclude var /var/www/project/ user#production.com:/var/www/project/httpdocs/ | grep -v '/$'
Operating system (Running Xubuntu):
Distributor ID: Ubuntu
Description: Ubuntu 11.10
Release: 11.10
Codename: oneiric
rsync version:
rsync version 3.0.8 protocol version 30
Copyright (C) 1996-2011 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
Capabilities:
64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
append, ACLs, xattrs, iconv, symtimes
Perhaps not a critical question, but it's bothering me nonetheless.
I also ran into the same problem. Rsync excludes the following types of files if -C option is used:
static char default_cvsignore[] =
/* These default ignored items come from the CVS manual. */
"RCS SCCS CVS CVS.adm RCSLOG cvslog.* tags TAGS"
" .make.state .nse_depinfo *~ #* .#* ,* _$* *$"
" *.old *.bak *.BAK *.orig *.rej .del-*"
" *.a *.olb *.o *.obj *.so *.exe"
" *.Z *.elc *.ln core"
/* The rest we added to suit ourself. */
" .svn/ .git/ .hg/ .bzr/";
"core" files are core dumps for terminated programs, so typically you do not want to copy these files. The problem is when you have, for instance, a directory called "core".
The solution is to use the "--include" option, or create a filtering file containing a rule like:
+ core
and then use "--filter=filename".