uArchSim 2012 Basics of team development

1. uArchSim 2012Basics of team development PavelKryukov 13.10.2012

2. Using E-mail

3. E-mail address • Good e-mail address is useful. It can be easily spelled verbally or by phone. If it is written, chance of mistake become less. • Unreadable e-mail address may create unnecessary preconceptions. • You can always understand, who is sender or receiver of e-mail without lookups to address book. • It’s easy to set up mail redirection from your old address. • frtk.ru doesn’t support Google+ yet. Probably we will use it for hangouts.

4. E-mail basics • Make ‘Reply All’ instead of ‘Reply’if it is necessary. Previous participants of conversations will be added to CC list, so they will be in the know. • Do not use ‘Reply All’ if you started to discuss something private. Others usually do not want to listen your conversation. • In short, always look at ‘To:’ and ‘Cc:’ fields of your message. • Never change topic on reply! Such letters are difficult for classification by people and mail clients. • Do not create silly topics to message (e. g. ‘hello’ or ‘patch’). Try to explain what is in the message, respect the recipient! • If your message consist only of topic, add ‘<eom>’ in the end of message. Recipient won’t spend time on downloading message.

5. Common abbreviations • (J)FYI — (just) for your information • ASAP — as soon as possible • AFAIK — as far as I know • IMHO — in my humble opinion • IIRC — if I recall correctly • BTW — by the way • EOM — end of message (see previous slide)

6. Using Google-groups • Google group is, firstly, a special e-mail address. When you send a message on this address, it is received by all subscribers. • You can view groups through web interface: https://groups.google.com/ • Always check presence/absence of Google-group e-mail address in ‘To:’ field! • Remember, we use only English language in our conversation.

7. Code Style

8. Why code style is so necessary? • Everybody has (I hope) its own style of writing code. It can be extremely practical, but what happens when you work in team? • if (a == b) { • if( a!=c) • { • if (c > 0) • { • x*=*y; • } • else { statement2; } • } else • { • statement3; • } • To avoid horror like this, code style should be unified. We uses code style of MIPT-VIS project (http://code.google.com/p/mipt-vis/wiki/CodingStyle) for a long time and going to support this tradition. Please study it!

9. Version control system

10. SVN • How to synchronize work with your colleague? You may send modified files друг другу, but you will face difficulties on merges. • The solution is to create one server with most relevant version. This server is called ‘repository’ • Members can download copy of repository to own computer (‘working copy’), this is called checkout. • Members of team can send their changes to repository (commit) and download from it changes of other users (update). • SVN has special interface if your changes conflict with changes of other people in team (merge-conflict). • For traffic economy, SVN transmits only differences of files, called ‘patches’ or ‘diffs’ • SVN repository saves all committed changes.

11. SVN work cycle Checkout Work with local copy Commit Update

12. How to install • On Windows we recommend to install TortoiseSVN • http://tortoisesvn.net/ • On Linux SVN is provided by main repositories, so you just need to run command like in Ubuntu: • sudoapt-get install subversion

13. Main commands • Checkout is operation of initial download of sources from repository. Syntax is following: • svn checkout <address> <localcopy> --username <name> • Update is operation of downloading changes of repository version to already checkouted local copy. • svnup [-r <revision number>] • Commit is operation of uploading changes of local copy to repository • svn commit -m <message>

14. Patches • You can create patch with command • svn diff > my.patch • or just look at it with • svn diff | vim – • svn diff | less • To apply a patch, run command • patch –p0 < my.patch • You may revert patch using command • patch –p0 –R < my.patch

15. Add and delete files • If you add new file to local copy, SVN won’t know about this file, e.g. on commit. You need to show this fact to SVN: • svn add newfile • The same thing happens with deletion. If you delete some file with ‘rm’ command, after next SVN update it will be restored. To delete file from repository, run command • svndelete oldfile • and on next your commit file will be deleted.

16. Your hometask • In our repository we’ve got file ‘members.txt’. You need to add your name to this file. • https://code.google.com/p/uarch-sim/wiki/HowToMakeYourFirstSVNCommit Step by step instruction • https://code.google.com/p/uarch-sim/wiki/SVNCheatSheet Cheat sheet on main SVN commands. It may be necessary in future.

17. Separate build

18. Object files • C++ files can be separated in two types: headers (.h) and translated files (.cpp). • Headers are not compiled. It is needed just to declare classes, methods and functions common for some .cpp files. • .cpp files are compiled independently. If your headers are correct, you may compile main.cpp to objective file main.o, after two hours functions.cpp and so on. • Special part of compiler is linker. Linker can connect objective files to one executed file or library. • This scheme is useful because if you got two projects with common .cpp files, you doesn’t need to compile this files two times.

19. Example of project builds • gcc funcsim.cpp –c • gcc memory.cpp –c • gcc decoder.cpp –c • gcc perfsim.cpp –c • gccfuncsim.omemory.odecoder.o –o funcsim.out • gccperfsim.omemory.odecoder.o –o perfsim.out

20. Advanced example of project builds • gcc funcsim.cpp –c –O2 –Wall –std=c++03 –Werror • gcc memory.cpp –c –O2 –Wall –std=c++03 –Werror • gcc decoder.cpp –c –O2 –Wall –std=c++03 –Werror • gcc perfsim.cpp –c –O2 –Wall –std=c++03 –Werror • gccfuncsim.omemory.odecoder.o –o funcsim.out-larch • gccperfsim.omemory.odecoder.o –o perfsim.out –larch • It’s too complicated for typing by hands, isn’t it? • Do we know what files should be rebuild?

21. Makefiles

22. Makefiles • Makefileis a file with rules of build (targets). • Make command decides what files are not created yet or become obsolete and creates it according to rules in Makefile. • <name>: <dependencies> • -TAB-<command> • program: func.o main.o • gcc func.o main.o –o program • If dependency is not created or is obsolete, it is rebuild according to rules

23. Automatic variables • $@ — target name. • $< — first dependency name. • $? — all dependencies more relevant than target • $+ — all dependencies • $^ — all dependencies without repeats • $? — only changed dependencies • program: program.omain.o • gcc $+ –o $@

24. User variables • You may create own variables with = operator, and get with $(name) operator • SRC_DIR=source • C_FILES= $(SRC_DIR)/func.cpp $(SRC_DIR)/main.cpp • Variables can be set from console: • make all DEBUG=1 • You may use directives: • ifeq ($(DEBUG), 1) • C_FLAGS= -O0 –g –DENABLE_TRACE=1 • else • C_FLAGS = -O3 • endif

25. Common-used variables • CC — C compiler • CFLAGS — C compiler flags • LDFLAGS — Linker flags • CXX — C++ compiler • CXXFLAGS — C++ compiler flags

26. Substitutions and implicit targets • OBJS_FILES= ${C_FILES: $(SRC_DIR)/%.c=$(OBJ_DIR)/%.o} • In OBJS_FILES we will get objective files that corresponds to c files. It makes easy to create targets using % symbol: • $(OBJ_DIR)/%.o: $(SRC_DIR)/%.c • $(CC) $(CFLAGS) $< -c -o $@

27. Using of shell • You are free to use common shell commands, e.g. ‘rm’: • clean: • rm -rf $(OBJ_DIR) • rm -rf $(BIN_DIR) • $(shelluname -m) returns architecture of current PC(i686 orx86_64 ) • $(shelluname -o) returns OS name(GNU/Linux, Cygwin…)

28. Example of Makefile CC := gcc CFLAGS := -Wall ifeq ($(DEBUG), 1) CFLAGS := $(CFLAGS) -O0 -g else CFLAGS := $(CFLAGS) -O2 endif SRC_DIR := source BIN_DIR := bin OBJ_DIR := obj C_FILES := $(SRC_DIR)/func.c$(SRC_DIR)/main.c OBJS_FILES := ${C_FILES:$(SRC_DIR)/%.c=$(OBJ_DIR)/%.o} $(OBJ_DIR)/%.o: $(SRC_DIR)/%.c $(CC) $(CFLAGS) $< -c -o $@ $(BIN_DIR)/program: $(OBJS_FILES) $(CC) $(LDFLAGS) $^ -o $@ all: build_dirs$(BIN_DIR)/program build_dirs: mkdir –p $(BIN_DIR) mkdir –p $(OBJ_DIR) clean: rm -rf$(BIN_DIR) rm -rf$(OBJ_DIR)

29. Thank You