Lately I have challenged myself to build the Eclipse IDE from the source code. This will open an opportunity to start playing around with the code, and make some changes.
I found the following tutorial to guide me through the procedure: http://www.vogella.com/tutorials/EclipsePlatformDevelopment/article.html
Especially chapter 13 of that Tutorial is helpful. Apparently I need to have the following software installed on my (Windows) machine:
Git
Maven Version 3.3.1 (make sure that the bin folder where you extract Maven is added to the PATH)
Oracle 1.8 JDK or higher
I have all this software on my desktop - so I'm ready to go. I start by cloning the newest Eclipse repository and it's submodules via Git to some folder on my machine:
git clone -b master --recursive git://git.eclipse.org/gitroot/platform/eclipse.platform.releng.aggregator.git
This takes a couple of minutes. Maybe half an hour at most. Eureka - the folder is now pretty full with the Eclipse source code! The vogella tutorial proceeds with the actual build command. I open the command prompt in Windows and surf (cd..) to the right spot. Then I type the command:
mvn clean verify
I first got some errors. But thanks to the StackOverflow community, they are solved now. Please refer to this link for more info: https://stackoverflow.com/questions/37645180/building-the-eclipse-ide-from-scratch
Eclipse builds. And it builds. And it keeps building for hours. After many hours, I get the message that the build has finished. I'm amazed it took such a long time, since my computer is quite a beast:
> CPU: Intel Core i7-4790K CPU #4.00GHz
> RAM: 16.0GB
> System type: 64-bit OS
> Windows 10 Home
Anyway, after the build has finished, the JUnit testing automatically starts. I have no option to skip it. I wait for some more hours, until I really need to stop the system and go home. I close the command prompt - knowing that I interrupt the JUnit testing. But who cares :-).
I check my filesystem, and cannot find the files about which the Vogella tutorial speaks:
eclipse.platform.releng.tychoeclipsebuilder/sdk/target/products/*
Help.. was the whole build procedure done for nothing? I want to redo the build, but is there a way to skip those JUnit testings?
EDIT: I followed the advice of Mr. Gerold Broser and added the -DskipTests flag to the mvn clean verify command. I believe that Eclipse is now building without doing all the JUnit testing. Nevertheless, I still feel like the build takes an eternity. I'm now waiting for 4 hours. Is this normal? Are there ways to tell the maven build tool that it can use all 4 CPU cores?
EDIT: The Eclipse build has finally stopped. Unfortunately, it is no big success. I get a very lengthy error message. The build has failed. I've opened up another StackOverflow post to get some help:
https://stackoverflow.com/questions/37662645/building-eclipse-from-scratch-build-failure
Hope you can help me out.
See Maven Surefire Plugin / Skipping Tests:
You can also skip the tests via the command line by executing the following command:
mvn ... -DskipTests
Related
I want to setup kafka-manager by Yahoo. While starting with this command: ./sbt clean dist. I'm getting below console message but nothing else. I've also downloaded the required jar(sbt-launcher). Please help.
Getting org.scala-sbt sbt 0.13.9 ...
I believe there is nothing wrong with this. Allow some time and the build will proceed normally, once the dependencies are downloaded. To verify this, you can run sbt in verbose mode using -v option and you will be able to see dependencies which are being downloaded and are not visible.
Instead of running sbt in verbose mode, you can also have a look at the update log by running
$ tail -f $HOME/.sbt/boot/update.log
It requires internet connection on your machine where you want to build it, because there are lot more scala dependencies to be downloaded up on build command (./sbt clean dist). It has taken around 2 hrs to download all the jars.And finally it works for me.
I recently started using qemu and it's a great tool when you don't have the required hardware to run your firmware (currently using it for cortex-m3).
Now what I want to do is to do some test coverage with it. I tried using GNUC ARM Eclipse, and I've been successfull compiling and executing the code in qemu, but whenever I add the -fprofile-arcs -ftest-coverage flags (for the project and then for the desired file to run coverage) I am able to create the .gcno file, which means that after executing my code it will generate a .gcda file and then I should be able to see the coverage.
Thtat's where everything goes wrong. I was able to generate a .gcda file but whenever I try to open any of them, eclipse tells me that it wasn't able to open the file because it was null. I've tried replicating the procedure in another computer, but I haven't been successful creating the gcda file (probably different binaries).
At this point I don't really know how to proceed. Should I abandon ARM Eclipse and stick to makefiles (is it possibll to run gcov this way?) or am I missing something really small that is fixable?
PS: I using windows 7 64 bits, the latest versions available on the GNU ARM Eclipse website. Also the idea of doing it via makefiles just occurred to me (it was a stresfull day, it's really late) so I haven't tried it yet, I've only tried executing the code, but without coverage.
As far as I know, qemu is not able to generate DWARF information. But there is a project with the proposal of code coverage with qemu: Couverture Project
When you use qemu as a user space emulator (see also the qemu documentation) you actually can measure the code coverage as usual. In this mode qemu has the full access to the host file system.
For a CMake project you can simply use the CROSSCOMPILING_EMULATOR property of your test executable, e.g.:
if(CMAKE_CROSSCOMPILING)
set_target_properties(mytest
PROPERTIES
CROSSCOMPILING_EMULATOR "qemu-${CMAKE_SYSTEM_PROCESSOR};-L;$ENV{SDKTARGETSYSROOT}"
)
endif()
With this setting ctest will use qemu for running the test and will write the .gcda files to the usual location in your build directory.
I have been using Linux for less than 24 hours, so please, if there is anymore information I should provide, do be quite specific about how to get that information.
I've been trying to install Node.js, express.js and eclipse. As you can see, ubuntu does recognise both node.js and express as installed on my system (I think!) and I got the Nodeclipse-extension for eclipse, but still Eclipse doesn't seem to recognise either node.js or express (see my image below). I also want to add that the time occurrence of the error, I was trying to build a Node.js Express Project.
At this point, how do I go about debugging the situation? The folder location shown in the image does not fully exist. I can only go as far as [...]/bin/ - I have been looking at error messages similar to mine, and it seems like people are getting such errors because they're lacking an installation, however, from my screenshot provided, I would think everything is installed as needed.
I am using a native 64-bit windows laptop with Linux (Ubuntu) installed through a virtualbox. Ubuntu is 14.04 LTS and just 32-bit, as I don't have spare 2 gb ram to give the 64-bit version. Sadness.
I'd appreciate any help!
In Eclipse Windows -> Preferences -> Nodeclipse
check what is configured for Node and Express
Read more on http://www.nodeclipse.org/
I found a solution, which worked for me:
WINDOWS:
I did double installations of the needed modules. They were both located in C:/Users/X/AppData/Roaming, in the Eclipse directories and finally in C:/Program Files/nodejs. When I deleted all the node_modules, besides critical ones for nodejs to function and then ran Eclipse with Nodeclipse, it seemed to function and Eclipse automaticly defined folders in its own subdirectory, in which Express were located.
UBUNTU:
Delete all node_modules files and run Eclipse with Nodeclipse. See the windows explanation for a more detailed overview. Same problem and solution seemed to be present for both systems. Do note that the file directories are of course not completely interchangeable. You'll need to locate your instances of node_module.
I am compiling the OpenCascade Community Edition (https://github.com/tpaviot/oce/) on Windows 7. The build files are generated with CMake 2.8.8.
When I use the "Visual Studio 10" generater and compile the projekt with msbuild from a console the whole build process takes 17 minutes. On the other hand, if I select "Eclipse CDT4 - NMake Makefiles" and start the build process in Eclipse, it takes 87 minutes.
Does anyone know the reason for this difference? Is there a way to make the Eclipse build much faster?
With msbuild I do NOT use parallel builds. Also when I take a look at the task manager it seems as if the CPU usage of both build processes is nearly the same.
I have searched a lot, but did not find any clue. Thank you in advance.
Yes, VS IDE projects do parallel builds. nmake does not. One think you could try is jom or some other tool, see here for information:
http://www.kitware.com/blog/home/post/434
I did not notice that you said msbuild is not doing parallel. How did you do that? It will be default do parallel target builds.
I have downloaded a project which uses sbt as its build system and I want to build it. You'd think it would be as simple as typing "sbt" or something, but no.
I thought I'd add a question for this because it can take literally hours to figure this out on your own. I'm not joking.
tl;dr:
sbt compile
If you want to run it:
sbt run
To see what other targets are available:
sbt tasks
To get some (other) help, but mostly targeted at commands typed from the sbt console (ie, running sbt without parameters):
sbt help
This all assumes sbt version >= 0.10.0. To see what version of sbt is in use, do:
grep sbt.version project/build.properties
If there's no such file, and there's a file with extension ".sbt" on the base directory (not the project directory), then it's >= 0.10.0. Of course, if the grep works, it should tell you the version.
First, you'll want to use sbt-extras, because that automatically downloads and uses the right version of sbt. Trying to use the wrong version of sbt (newer or older than what the project you're trying to build says it requires) won't necessarily work, and may cause strange errors.
Run it:
~/path/to/sbt-extras/sbt
Wait for it to start up and download everything. If you need to use an authenticated proxy, you'll need to edit the script to specify the username and password for the proxy.
Check the version of Scala that sbt thinks it needs to build against (at the end of the output, if everything worked). If this is OK, fine, you don't need to do anything. If it isn't, you can temporarily specify a version explicitly with ++, e.g.:
++2.8.1
(If you want to make this permanent, you can edit the build definition files, but as that involves making a change to files under version control, that might not be what you want to do.)
Now, if you are using an older version of sbt, don't skip the next step! You could get strange errors if you do.
update
Now you can build and test what you've built:
test
If you get an error "Filename too long", this is not an sbt-specific problem, it's a scala problem, which most frequently affects Ubuntu users (technically, for Unbuntu users it's generally related to home directories encrypted with encfs). If you are using Scala >= 2.9, edit the build to use the scalac command-line option that allows you to specify a maximum filename length. Otherwise, if you are on Linux, you can redirect the build to /dev/shm or /tmp, by running these commands in a shell prompt (don't background sbt with CTRL+Z on Unix, because it may appear to stop working properly):
rm -rf target
ln -s /dev/shm target
(you may have to execute these commands in project/build instead or as well.)
Actually, it's probably better, and may even be more secure, to create a subdirectory of /dev/shm or /tmp and use that instead.
The compilation result should appear in target. You might then want to run it, if it's something you can run:
run
If everything looks OK, you can optionally publish the result locally so that the result can then be picked up automatically by other sbt builds:
publish-local
I don't think I could explain it better that the Getting Started Guide could. Please read the first 6 parts of it, which shouldn't too long time, to get it up and running.