Sharing SDK Projects/Working in a Team

Size: px

Start display at page:

Download "Sharing SDK Projects/Working in a Team"

Walter Cole
6 years ago
Views:

1 Sharing SDK Projects/Working in a Team This tutorial illustrates the usage of SDK in a team setting. In particular, it demonstrates: 1. How to organize SDK projects so that they can be placed in version control and 2. How to check out and build SDK projects from the command line. While this tutorial uses SDK, none of the steps below are specific to SDK. They are equally applicable to all kinds of Eclipse projects. Requirements Outline SDK version 12.1 or later. This tutorial consists of the following parts: 1. Installing a version control plugin (Team provider in Eclipse lingo). This tutorial uses egit. 2. Starting development. From existing SDK projects in a repository From scratch: adding projects to an empty repository. 3. Daily workflow Making modifications to application code and Checking in changes 4. Batch Mode Flow Checking out projects from command line Building projects from command line Installing a version control plugin The default installation of Xilinx SDK does not have any integration with version control systems (VCS). So the first step is to install plug-ins that will provide support for the VCS in use. In this tutorial, we'll use git as the VCS. However, note that plug-ins that support CVS, SVN, Perforce, Mercurial and other common VCS are all available online. The Eclipse plug-in for git is called egit, and is available at To install egit, perform the following steps: 1. Open SDK. 2. Click on Help -> Install New Software. 3. In the work with field, specify: and press enter. Note that if you are behind a firewall, make sure Eclipse knows about the proxy server to use (Window -> Preferences -> General -> Network Connections). 4. Select to install "Eclipse Git Team Provider (Incubation)" and click on Next. plan9/projects/sdk/ /DocSharingProjects 1/16

Note 5. Accept the license terms, and click on install. 6. Eclipse will prompt you to restart SDK. Select Yes to restart SDK. Git is not a easy to use version control system.

2 Note 5. Accept the license terms, and click on install. 6. Eclipse will prompt you to restart SDK. Select Yes to restart SDK. Git is not a easy to use version control system. The only reason we chose to use git for this example is because of its popularity. If you are new to version control, we recommend using Mercurial or SVN Starting development This section describes how to get started working with a source control repository. First we look at how a new user can check out projects from a repository already containing SDK projects. Then we look at how a user can populate a repository with initial contents. From existing git repository In a typical scenario, SDK projects are already present under source control, and a new user would like to check-out those projects and run or modify them. Eclipse makes this process extremely simple. For purposes of this example, we will work with a sample git repository present here: git://github.com/vsiva/sp605-lwip.git. This repository contains hardware for a SP605 board, and an echo server application that runs on that board. To import these projects into SDK, perform the following steps: 1. Open SDK with a fresh workspace. 2. Deselect Project -> Build Automatically. We do this only because it makes it easy to understand what files have been imported from the repository. 3. Select File -> Import -> Git -> Git Repository plan9/projects/sdk/ /DocSharingProjects 2/16

3 4. Specify the repository location in the next page of the wizard. In the URI field, enter git://github.com/vsiva/sp605-lwip.git. Eclipse will then automatically fill in the values for the remaining fields. Press next. See screenshot below for how this wizard looks: plan9/projects/sdk/ /DocSharingProjects 3/16

4 5. Leave the defaults in the branch selection page of the wizard. We will use the master branch of git. Press next. plan9/projects/sdk/ /DocSharingProjects 4/16

5 6. Finally, specify where the local repository should be setup. git and Mercurial are Distributed Version Control Systems (DVCS) in which every user has the complete repository locally. All changes can be commited to this local repository. If needed, changes from this repository can be then synchronized with a global repository. For purposes of this tutorial, we will store the local repository at C:\code\localrepo\. You can specify any other location, but just make sure that the path does not have spaces in it. We also select to Import projects after clone. plan9/projects/sdk/ /DocSharingProjects 5/16

7. Once git completes cloning the remote repository (referred to as origin), it will then import the projects stored in that repository into your workspace.

6 7. Once git completes cloning the remote repository (referred to as origin), it will then import the projects stored in that repository into your workspace. The example repository contains 3 projects (hardware, bsp and echo server application), and so your workspace should now contain these three projects. plan9/projects/sdk/ /DocSharingProjects 6/16

8. Your workspace is now setup for working with the application. Before building the application, take a moment to see what files have been imported from version control.

7 8. Your workspace is now setup for working with the application. Before building the application, take a moment to see what files have been imported from version control. In particular, take a note of the following: In the hardware project (hw_sp605), the following files are present: This bitstream, BMM and the hardware specification XML file. The BSP project contains the Makefile, libgen.options and the MSS file. In particular it does not contain the microblaze_0/ppc440_0, etc generated folders, or the libgen.log files. These files are generated, and hence are not necessary to be checked into version control. In the C Application (lwip_echo_server_0), only the source folder is checked in. Debug or Release folders are again generated, and should not be checked in. In all 3 projects, meta files such as.project,.cproject and.sdkproject are also checked in. These will not be visible by default, but you can modify the filters in the explorer view to show.* resources, and then notice that these files are also checked in. See screenshots below on how to modify the filters and the resulting explorer view. plan9/projects/sdk/ /DocSharingProjects 7/16

8 plan9/projects/sdk/ /DocSharingProjects 8/16

9 9. Now you can build the application manually, or simply turn on Project -> Build Automatically. This should build both the BSP and the application, and you should see the application built successfully. Initializing a repository with SDK projects The previous section talked about how to start working with SDK projects when they are already present in a repository. This section details how to create a sample SDK project, and then add it to an empty repository. This step will be performed once by the first developer when starting a project. 1. Open SDK with a fresh workspace. 2. Deselect Project -> Build Automatically. We do this only because it makes it easy to understand what files have been imported from the repository. 3. Create a hardware platform: File -> New -> Xilinx Hardware Platform Specification Provide a name, and an XML. Deselect the Use Default Location, and provide the following location C:\code\localrepo2\hw. Click Finish. This will create the hardware platform (hw) in folder C:\code\localrepo2. 4. Click on File -> New -> Xilinx C Project. Deselect the Use Default Location, and provide the following location C:\code\localrepo2\hello_world_0. Click Next. Make sure that the new BSP will be created at folder C:\code\localrepo2\hello_world_bsp_0. Click Finish. 5. At this point, you'll notice that the folder C:\code\localrepo2 contains all 3 projects (application, bsp and hardware). Now we can add all 3 projects to version control, and create a repository at C:\code\localrepo2. 6. Select all 3 projects, right click, and then select Team -> Share Project. plan9/projects/sdk/ /DocSharingProjects 9/16

10 8. In the next page, git will now prompt us to create a repository. Select all 3 projects in the window, then click on Create Repository. It is important to get all the settings correct in this step, so make sure your settings look like the ones shown in the screenshot below. plan9/projects/sdk/ /DocSharingProjects 10/16

$9. Now we have a git repository at C:\code\localrepo2. Click Finish. 10.$

11 9. Now we have a git repository at C:\code\localrepo2. Click Finish. 10. At this point, we have added the 3 projects to git, but none of the files inside the projects have been added to version control. The next steps detail how to specify the files to be tracked in git. 11. Select all 3 projects, right click and select Team -> Add to Version Control. This lets git know that the contents of all 3 projects should be tracked. Note that rather than adding files individually, we add everything inside the project. We can do this only because we have not built any artifacts. As a result, all files that are present within the projects are source files that need to be tracked. plan9/projects/sdk/ /DocSharingProjects 11/16

12 1. Select all 3 projects, click on Team -> Commit to commit these changes. plan9/projects/sdk/ /DocSharingProjects 12/16

13 1. A commit dialog will now show up. Confirm that it looks close to what is shown in the screenshot below. In particular, note that we are not saving any Debug/Release folders inside the app, or libgen.log/microblaze_0/ppc440_0 etc inside the BSP. plan9/projects/sdk/ /DocSharingProjects 13/16

$We have now created a git repository at C:\code\localrepo2. The structure of this repository should look similar to the structure of the repository we cloned from github in the previous section.$

14 We have now created a git repository at C:\code\localrepo2. The structure of this repository should look similar to the structure of the repository we cloned from github in the previous section. Daily Workflow Once the projects are imported into a workspace, making modifications to a project, and checking in changes are fairly trivial: Make a modification to a C file. Note that the icon for the file, the folder it is present in, and the project it is present in, all change to indicate that there are uncommited changes. Right click on project and click on Team -> Commit to commit these changes to the repository if you'd like. Batch Mode Flow plan9/projects/sdk/ /DocSharingProjects 14/16

15 Checking out projects from repository Checking out a repository from the command line is straightforward, just follow instructions provided by the VCS. For git: $ cd /cygdrive/c/code $ git clone git://github.com/vsiva/sp605-lwip.git should create a local clone of the remote repository. The contents of this folder match exactly what is present in the repository when cloned via Eclipse. This repository, as we know, contains 3 SDK projects: hw, bsp and application. Building the application from command line: Using Eclipse To build the application, open a SDK Bash shell, and perform the following steps: $ $XILINX_EDK/SDK/eclipse/nt/eclipse/eclipsec.exe -nosplash -application org -import /code/sp605-lwip/hw_sp605 \ -import /code/sp605-lwip/bsp_sp605/ \ -import /code/sp605-lwip/lwip_echo_server_0 \ -data /Temp/wspace \ -vmargs -Dorg.eclipse.cdt.core.console=org.eclipse. $ $XILINX_EDK/SDK/eclipse/nt/eclipse/eclipsec.exe -nosplash -application org -build bsp_sp605 -data /Temp/wspace/ -vmargs -Dorg.eclipse.cdt.core.console=org.eclipse. $ $XILINX_EDK/SDK/eclipse/nt/eclipse/eclipsec.exe -nosplash -application org -build lwip_echo_server_0 -data /Temp/wspace/ -vmargs -Dorg.eclipse.cdt.core.console=org.eclipse. In the above log, we issue 3 commands: 1. The first command imports the 3 projects (from C:/code/sp605-lwip/, or wherever the repository was cloned using git) into a workspace C:/Temp/wspace 2. The second command builds the software platform. 3. The third command builds the C application project. For more information consult the following pages: These steps mimic the operations done in the Eclipse GUI from the command line. Building the application from command line: Using make An alternative approach to building projects from the command line is to use make. However, this can be done only for projects where users choose to write their own Makefiles rather than relying on Eclipse automatically generating Makefiles for them. In such a case, users would typically have checked in their Makefiles into source control, so it is straightforward to simply call make inside their project. Conclusion This tutorial demonstrated how to use git plugin with Eclipse. Other version control systems differ in minor ways, but the overall approach remains very similar. Check- in only sources into version control. Do not check in build artefacts. From Eclipse, import the projects (without copying them into the repository). Make changes to the sources, and then commit the changes: use Eclipse GUI, or command line tools to perform VCS actions. If you use Eclipse's auto generation of Makefiles, then you need to call eclipse in headless plan9/projects/sdk/ /DocSharingProjects 15/16

16 Known Issues Attachments mode to build the project from command line. If you checked in your own Makefile (Standard Make Project), then you can simply call make to build the project from command line. BSP projects are standard make projects, so they can built simply by calling make, or by calling Eclipse in headless mode. Software Repositories: The list of software repositories is not maintained in any version controllable file. It is a workspace setting presently. As a result, every user needs to manually set the list once the projects are checked out of source control. A side effect of this is that the BSP will fail to build if software repositories are not present in the same folder as present in the libgen.options file. sdk_install_egit.jpg (51.8 KB) - added by siva 5 months ago. "select egit plugins" import_from_git_repo.jpg (25.1 KB) - added by siva 5 months ago. git_repo_location.jpg (35.3 KB) - added by siva 5 months ago. git_branch_selection.jpg (24.2 KB) - added by siva 5 months ago. git_local_destination.jpg (32.6 KB) - added by siva 5 months ago. explorer_view_post_import.jpg (24.2 KB) - added by siva 5 months ago. customize_view.jpg (36.2 KB) - added by siva 5 months ago. explorer_with_dotfiles.jpg (31.6 KB) - added by siva 5 months ago. filter_dot_files.2.jpg (29.5 KB) - added by siva 5 months ago. team.share.jpg (39.4 KB) - added by siva 5 months ago. createrepo.jpg (39.2 KB) - added by siva 5 months ago. init.add.jpg (49.9 KB) - added by siva 5 months ago. init.commit.details.jpg (70.6 KB) - added by siva 5 months ago. init.commit.jpg (51.8 KB) - added by siva 5 months ago. plan9/projects/sdk/ /DocSharingProjects 16/16

CSE 332: Data Structures and Parallelism Winter 2019 Setting Up Your CSE 332 Environment

CSE 332: Data Structures and Parallelism Winter 2019 Setting Up Your CSE 332 Environment This document guides you through setting up Eclipse for CSE 332. The first section covers using gitlab to access