Sometimes you have to update many files at once. If you are using an IDE there is option during replace “search in all files”. I’ll show you how make those massive changes faster, using just Linux command line. Place this file in ~/bin/repl
#!/bin/sh
PATTERN="$1"
FROM="$2"
TO="$3"
FILES=$(grep -le "$FROM" `find . -name "$PATTERN"`)
echo Files: $FILES
sed -i "s!$FROM!$TO!g" $FILES
Sample usage is:
repl "*.cpp" "loadFiles" "retrieveFiles"
Some explanation about script:
- grep -l: shows on stdout only filenames of matching files
- grep -e: accepts pattern as argument
- sed -i: changing files “in place”
- grep -le: we want only files that will match $FROM to be updated (minimizes build time after change)
Pretty easy and powerful. Enjoy!
Status command is very important part of any VCS (Version Control System) local interface. It allows you to check your workspace state and ensure correct commit will be created.
Perforce is a commercial VCS that is similar to CVS (revisions per file) and SVN (global revisions of whole tree). It’s support for status command is very clumsy. Let’s check how we can emulate status with this tool using small script:
echo === extra files not tracked by Perforce ===
find . '!' -type d '!' -executable | p4 -x - have 2>&1 | grep 'not on client' | \
sed '/\/moc_/d;/\.so/d;/\.o /d;/Makefile /d;/\.a /d'
echo === Current changelist ===
p4 changelist -o
As you can see we implemented “ignore” mechanism in above script (by sed filtering). “Extra files not tracked by Perforce” reflects “?”-status from CVS/SVN. “Current changelist” reflects “A,D,U”-statuses from CVS/SVN.
By using such script you can ensure your commit contains all files from your workspace, thus will be buildable on other developers’ machines.
Last week I’ve been observing details of integrating source code coming from three different development teams (located in different countries). Each team owns some subset of modules and has R/W access only to those modules. Of course compile dependencies cross the borders in many places, so global changes usually done in one commit had to be split into at least two commits (because of missing W permission for someone).
There was one development branch and one integration branch. Development branch most of this time was in not “buildable” state (permanent build error), so no one was able to ensure changes are not breaking the build before commit until stabilisation. Integration branch was loaded using files copied from development branch when stable state was achieved (I know, lame). This integration style (allowing for non-buildable commits on development branch) blocks parallel integrations (one have to wait for stable state on development branch).
Are there better ways to organise such integration?
(more…)
Recently I’ve found my old project that was prepared during studies at Warsaw University of Technology. It’s called DCSim (Digital Circuit Simulator) and is written using C++ with old Athena widget library (does anyone remember libxt6.so?).
(more…)
Good software developers are lazy persons. They know that any work that can be automated should be automated. They have tools and skills to find automated (or partially automated) solution for many boring tasks. As a bonus only the most interesting tasks (that involve high creativity) remain for them.
I think I’m lazy 
. I hope it’s making my software development better because I like to hire computer for additional “things” apart from typewriter and build services. If you are reading this blog probably you are doing the same. Today I’d like to focus on C++ build process example.
(more…)
