As given in mega-manual,
4.2.2.2. Creating the Project
You can create two types of projects: Autotools-based, or
Makefile-based. This section describes how to create Autotools-based
projects from within the Eclipse IDE. For information on creating
Makefile-based projects in a terminal window, see the section "Using
the Command Line" in the Yocto Project Application Developer's Guide.
I want to deploy a separate binary package, I don't want to create an image including my package. Isn't it possible to build a binary package like .ipk .deb .rpm using poky?
Yes, packages are always created. Autotools and Makefiles are for configuring/building software, so not really related to the question.
Use the PACKAGE_CLASSES variable in your configuration to select the package types you want to build with Yocto/OpenEmbedded. When you "bitbake recipe-name" the packages are built in the deploy directories under recipe WORKDIR.
Please don't expect the packages to be compatible with some other operating system though: they will be tailored for your specific configuration. If you already have an image running exactly that configuration, then it should be fine.
Related
I installed Rcedit for changing my file icon after exporting my game with Godot 3.2.2 stable.
But it only works when I uncheck embed pck. Else, it says that it can't find pck.
I want to embed the pck file with exe.
I also to change the file icon from default.
What can I do?
Edit: I also noticed now that, Rcedit is not working. It shows the custom icon when I check it in the folder. But when I bring it to desktop, it shows the default icon and it doesn't depends on presence recedit!
I am confused. Can someone solve it.
This is now a document known issue: Export with embedded pck is broken when changing PE metadata with rcedit. It has not been solved at the moment of writing. However, it should be solved for the next release (if there is another tool, similar to rcedit, which actually works in this scenario, that would be the solution. For you, and for Godot. I'm unaware of any).
Godot is not coming today, but will come tomorrow
-- Waiting For Godot.
Meanwhile, you will have to build your own export templates for Windows. To do that, begin with downloading Godot source.
Go to the Godot repository, select the branch you want (e.g 3.2) or the tag you want (e.g. 3.2.3-stable), and download to zip.
You will need Python. You will need pip, make sure it is up to date (python -m pip install --upgrade pip) and install Scons using pip (python -m pip install scons). You will also need the C++ build tools. I recommend using the Visual Studio Community installer and select "Desktop development with C++" (you don't really need Visual Studio, however in my experience using the Visual Studio installer to get them is more reliable than the standalone installer). Finally you can run scons platform=windows from the Godot source folder to build Godot.
The build system and the build process is explained in more detail in Introduction to the buildsystem. And, of course, Compiling for Windows.
Yet, the goal is not to build Godot. The goal is to build the Windows export templates. For that you are going to run these:
C:\godot> scons platform=windows tools=no target=release_debug bits=32
C:\godot> scons platform=windows tools=no target=release bits=32
C:\godot> scons platform=windows tools=no target=release_debug bits=64
C:\godot> scons platform=windows tools=no target=release bits=64
Oh, but, wait, before you do that… You need to find platform/windows/godot.ico in the source and replace it with the icon you want. Then build the Windows export templates.
Once you have your custom built export templates, you need to put them in %APPDATA%\Godot\templates\<version>\, where version matches what about says in Godot, (e.g "3.2.3.stable.mono"). And then you can build your game.
As you know, your game will appear with the default icon. What I describe here changes the default icon.
I've built a small desktop application with which I am trying to use a Setup project to allow other users to install it. But whenever I run this installer, it does not produce an executable file. This is my first time making a setup project.
My solution contains two projects. One is the setup project which installs the primary output from the other project. The other project is a WPF App that consists of two xaml files, a xaml.cs file for each, an App.config file, and an icon. It also has a few dependencies including one Assembly, two Frameworks, and a handful of Packages. The app works exactly as intended whenever I start a Visual Studio debugging instance on either Debug or Release configurations.
I followed these instructions to build my Setup and deploy my app.
Whenever I ran the resulting Setup, it installed an XML configuration file, a JSON file, a main application dll file, and a bunch of dll files for my assemblies. I looked into some resources on how to run the main dll file properly, only (A) I'm completely stumped by everything I find on that topic, and (B) I would rather just produce an executable file anyway, since I intend for this Setup project to be used by other people and it would be inconvenient to ask said others to jump through the same hoops just to run it.
Why does my Setup project not produce a .exe file? I see that a .exe file is produced in my bin folder whenever I build my project (and this .exe works), so I would think the setup project should also produce one of those, but it doesn't. What am I doing wrong with my Setup project or anything else?
The setup.exe is a bootstrapper over the setup.msi. We can install the content using .msi or by running .exe which inturn runs /gets the data from the msi. To enable setup.exe building, go to solution explorer -> project -> properties -> prerequisites. check the check box on the top "Create setup program to install prerequisite components". apply and rebuld the project. A setup.exe bootstrapper will be created allong with msi.
Switch to Release mode, then rebuild your setup project. If everything went well (check the output console), you'll find an MSI file inside {setup project folder}/bin/Release
In "system file" from your proyect installer, you shoud to add in "Application Folder" the next source = PublishItemsOutpuGroup. In my case functions well.
I was ordered to deliver an app in 2 versions : one demo/light (limitted features) the other full (all features). I have a boolean in code which tells which one is running. They both run as expected in the simulator or on a test device (iOS and Android).
Now I want to distribute them. So I read that it was possible with XCode to define different targets corresponding to the light / full versions and with Eclipse it was possible to define the base project as a library and then create 2 projects also corresponding to the light / full versions.
Before I start messing around with my app project, is there a recommended way to achieve my goal with CodenameOne maybe via build hints that would change the app name and the boolean inside the code depending on a build hint value ?
EDIT 19/09/2016 (working methodology)
Following Shai's advices here are the steps I followed to generate a light version based on the full one (in case someone encounters the same case) :
Under your IDE (Eclipse or whathever) copy and paste the base package in the src folder and rename it com.packageLIGHT.appName (simply append LIGHT to the package name, don't use underscore or space since it will be considered as an illegal character later by Apple)
=> So now in src folder you should have
src
|- com.packageLIGHT.appName
|- com.package.appName
Then in com.packageLIGHT.appName remove all files except MyApp.java (aka the main file). In this file add import com.package.myApp.*;
3.1. (ECLIPSE) In "Run/Run Configurations" menu copy the existing config and paste it as Simulator_MyAppLIGHT and in arguments change it to "com.packageLIGHT.myApp.MyApp".
3.2. (NETBEANS) The "Run/Set Project Configuration" does not seem to work as expected since any configuration that might be selected leads to the same default behaviour. However applying step 6. and running the project in the simulator afterward has the expected result.
Now you should be able to run both versions by running the different configurations.
For iOS (not sure if it is also needed for Android) you have to generate another pair of provisioning files. So move the existing ones in iosCerts/FULL and use CN1 wizard to generate the "light" version provisioning files where you'll adapt the package name to match "com.packageLIGHT.myApp". Store the generated files in iosCerts/LIGHT. There is no need to overwrite the existing certificates (more on certificate here).
Finally replace in "codenameone_settings.properties" the original package name with the "light" one for the lines codename1.ios.appid and codename1.packageName. Also change the iOS provisioning files to iosCerts/LIGHT or FULL depending of what you want to build.
Now when you send the Android / iOS build to CN1 server it will build either the "light" version or the full one depending on what package is written in "codenameone_settings.properties".
Please note : if at step 6. you get NullPointerException on build.xml on line 469 (android build) or 344 (iOS build) which deals with certPassword="${codename1.android.keystorePassword} (android build) or appid="${codename1.ios.appid}" (iOS build) and you're using CN1 plugin version 1.0.0 20160812 under Eclipse then Shai's comment below may be worth it
If you want 2 distinct versions of the same app then you need 2 distinct packages since the thing that defines the app uniquely in the store is the app package. There are two common ways to do it:
Place functionality in cn1lib and build two apps
Build one app and just swap the codenameone_settings.properties file
The first one should be pretty clear but might be a bit painful to work with as you can't run the cn1lib and might run into issues debugging it.
The second one is actually rather simple. Create the main version of the app then add the package to the demo version and copy the main file there.
To run the demo version just change the package in the IDE "run settings".
Copy your codenameone_settings.properties to a separate file and just replace all the regular package names to the demo package names. When you want to build the "demo" version replace the codenameone_settings.propeties files with one another, you can automate that with a script obviously.
I am relatively new to Selenium WebDriver and a self learner. I have created a webDriver project which consists of different packages and have made use of Page Factory concepts extensively. I use TestNg framework to run the suite to generate my report. So my test cases are also following the TestNG framework concepts.
Now my team wants to use my script to be run at every build to test the sanity. The build team just wants to run my whole script by just a click. It can be shell script command or .exe or jar. Build team uses linux m/c and they dont have Ecplise , TestNg installed in their machine. Their intention is whenever build is given they want to run my script by just a click or a command in Command Prompt.( it has to be that simple for them) and a report should be generated in some location in hdfs
My script runs on FF version 32 and Selenium webDriver 2.44.0
Would really appreciate if someone could give me a solution that actually works for my requirement.
I found a similar query from someone but i am not sure if the answer still suits.
How to make Java executable Jar file of WebDriver project
Could somebody please give me a solution. Or the solution mentioned in the above link stil is the best?
Regards
There are few ways to do it:
Use CI tool (Jenkins): You can set up your project in Jenkins and it will allow you to run the project in single click. Jenkins also provides you an option to run the tests periodically so you can configure it in such a way that it will always get executed after certain time period.Jenkins is also capable to trigger the execution if there is any changes in source code of tests. I'd suggest to use this tool. https://jenkins-ci.org/
Use .bat or .sh file: I am not sure if you are using any build tool like ANT or Maven, if you are using any one of them then you can write a .bat or .sh file to run the tests. ANT
If you are not using any build tool then start using, it will help to run the tests in simplest way.For me to run entire suite, I just type below command in terminal from root directory of project
ant run -Dsuite=all
If you are more concerned about system configuration for e.g. the system which will be used by build team does not have a specific version of browser or specific required library. Then I'd suggest to keep all essentials like browser installation files, libraries in your project directory. This is not a good practice but yes it will help others to run the tests smoothly.
I would suggest just exporting a jar file for your project. All the libraries will be packaged together in the jar files(including TestNG) and you can simply double click on the jar file to start your tests.
External resources (if any), will have to be available for the jar file though. So, you can provide the jar file and the external resources together. The external resources might include your test data (if any) or Portable Firefox(if you are using the portable version).
Steps:
Right click on Project -> Export -> Runnable jar file
Give a name and file path for the jar file
Select option - Extract required libraries into generated JAR
And Finish
Troubleshooting:
Check the java version for the machines that you will be running your jar file on. Programs compiled with java 7 will mostly not run if the machine has java 6. Either compile with java 6 or update the jre on the target machines.
If the jar file does not launch, try using Jarfix.
I am moving from Netbeans to Eclipse (on Ubuntu 12.0.4). I have a C application that consists of several sub projects which are libraries (shared and static), as well as stand alone executables.
I can't figure out how to create a 'parent' project foo, which contains component projects
foobar
foofoo
barfoo
barbar
Ideally, I want all the 'component projects' to be created under the folder foo, so that I have a directory structure like this:
/path/to/foo/foobar/ (contains foobar project files)
/path/to/foo/foofoo/ (contains foofoo project files)
/path/to/foo/barfoo/ (contains barfoo project files)
/path/to/foo/barbar/ (contains barbar project files)
Does anyone know how I can achieve this structure using Eclipse as IDE (with CDT)?
Last but not the least, I intend to create my C modules using the Autotools option. Will the generated files for Autotools be automatically updated as I add new header/source to a module - or do I need to manually maintain the Autotool files?
Friend,
I think there is no the "parent" C project. You can create a normal C project in IDE and add all dependencies into sub-folders. Then tell compiler your build procedure via Makefile. I think it's easy way as you have had experience on C application.
About autotools, once you update/add/remove your project file, I think you need to modify your Makefile to reflect your change and do clean and rebuild your project.
For other C build tools, you can use buildroot if you'd like.
The best way I can think to do this in eclipse is to create a separate workspace for the project e.g. foo, and then add the sub-projects (foobar, foofoo, etc...) as projects. This is generally a better approach to take with eclipse, instead of a single monolithic workspace. I don't know what the specific dependency structure for the sub-projects looks like, but you should be able to express it simply by using eclipse project properties. This can include a rollup executable sub-project that depends on the libraries.
Unfortunately, I'm not sure if eclipse cdt will maintain autotools files. However if not, it should be relatively easy to integrate and use some of the autotools binaries such as autoscan, and autoheader into the eclipse build commands.
At first you need to a working directory, Then you should new project, Then per file or per class (according to C++ or C ) append your files, it's much safe way. another way is not clean, i have experience. don't use them.