My question is the following:
do I need to recompile all the VxWorks O.S. libraries for the target architecture each time I switch between my projects, one for Pentium M and one for Atom?
If this is the case, is there some smart strategy to shorten the procedure?
In the case you have sources of vxworks in your distribution you can create source build projects for each BSP and build them. These projects produces the complete set of libraries. You can create VIP (vxworks image project) based on source build project and your image will be linked with the libraries you produced. One thing to remember - the source build project doesn't contain sources, but only links on them, so if you will change the source in one source build project it will be changed in all projects and the next build will change the produces library. So be aware of it. Hope this will help you.
The trick is to use SCCS (source code control system, like git, cvs, clearcase, whatever), then create two local workspaces from the same repo (one for Pentium M, and the other for Atom). When you make changes in one workspace you commit the change to the repo, and then merge those changes into the other workspace.
Related
I tend to build Yocto builds for various boards and versions(sumo, warrior, etc.,). To speedup the builds I use separate DL_DIR & SSTATE_DIR. The structure I followed is given below:
Single download dir for all the builds & boards (as most of the builds for different boards use same tool-chain)
Separate sstate cache dir for each board
My question is, Can I use single SSTATE_DIR to improve the performance and reducing the folder size? Have anyone tried it?
Suggestions and personal experiences are also appreciated.
You can share DL_DIR among all build directories and Yocto versions. Those are just tarballs of sources.
You can share SSTATE_DIR among all build directories, though it is beneficial only for builds sharing the same Yocto version, otherwise no size or speed improvement at all. This makes sense because many native packages and "base" target packages of machines of the same architecture (in your case aarch64) are identical for said machines and will make use of the shared SSTATE_DIR. For non-matching cases, new entries will be added to your SSTATE_DIR. When you have different Yocto versions, some package recipes have been updated and most often glibc, binutils and gcc are updated. Those are the packages used by almost all other package recipes, which effectively makes it impossible to re-use sstate-cache from earlier (or later) Yocto versions for package recipes that haven't changed since the package recipes they depend on are part of the sstate-cache for said recipes. Also, the Yocto version is in the filename of a sstate-cache entry so anyway they'll be rebuilt.
Which choices I have to build a VS2008 solution for different target frameworks, with only "one click"? I need to build for .net-2.0 and netcf-2.0.
The problem is that I need referencing different libraries for netcf-2.0.
I tried to do this with nant, but that seems to be a complicated task.
I don't use different build configurations.
When I did this I created a separate project for the CF version. Inside the CF version the Compile property group uses links to all the original source files.
The CF and full-framework libraries are covered by independent projects. Each project can have an independent set of post-build or pre-build tasks, an independent set of references, a distinct set of #defined symbols, etc.
In my case, not all code used in the full-framework version of the library gets compiled for the CF version. Using partial classes, I factor the code used only for the full-framework version into separate modules, and I don't add links for those source files into the CF project.
You could do the equivalent by using #if statements, and defining a CF symbol (or similar) in the .csproj file for the CF project.
Keep different projects in a single solution with the same file list targeted to different framework versions.
Or group projects/solution by framework version.
Have you tried creating separate build configurations for each of the target frameworks?
For example, copy your Debug config and modify to your matching conditions and name it as FrameWork_2_0 and so on...
And now you can simply call an MSBuild/NAnt task on your solution once for each configuration
There are often conflicts in the Xcode project file (Project.xcodeproj/project.pbxproj) when merging branches (I'm using git). Sometimes it's easy, but at times I end up with a corrupt project file and have to revert. In the worst case I have to fix up the project file manually in a second commit (which can be squashed with the previous) by dragging in files etc.
Does anyone have tips for how to handle merge conflicts in big and complex files like the Xcode project file?
EDIT-- Some related questions:
Git and pbxproj
Should I merge .pbxproj files with git using merge=union?
RESOURCES:
http://www.alphaworks.ibm.com/tech/xmldiffmerge
http://www2.informatik.hu-berlin.de/~obecker/XSLT/#merge
http://tdm.berlios.de/3dm/doc/thesis.pdf
http://www.cs.hut.fi/~ctl/3dm/
http://el4j.svn.sourceforge.net/viewvc/el4j/trunk/el4j/framework/modules/xml_merge/
Break your projects up into smaller, more logical libraries/packages. Massive projects are regularly the sign of a bad design, like the object that does way too much or is way too large.
Design for easy rebuilding -- this also helps if you're writing programs which must be built by multiple tools or IDEs. Many of my 'projects' can be reconstructed by adding one directory.
Remove extraneous build phases. Example: I've removed the "Copy Headers" build phase from all projects. Explicitly include the specific files via the include directive.
Use xcconfig files wherever possible. This also reduces the number of changes you must make when updating your builds. xcconfig files define a collection of build settings, and support #include. Of course, you then delete the (majority of) user defined settings from each project and target when you define the xcconfig to use.
For target dependencies: create targets which perform logical operations, rather than physical operations. This is usually a shell script target or aggregate target. For example: "build dependencies", "run all unit tests", "build all", "clean all". then you do not have to maintain every dependency change every step of a way - it's like using references.
Define a common "Source Tree" for your code, and a second for 3rd party sources.
There are external build tools available. This may be an option for you (at least, for some of your targets).
At this point, a xcodeproj will be much simpler. It will require fewer changes, and be very easy to reconstruct. You can go much further with these concepts to further reduce the complexity of your projects and builds.
You might want to try https://github.com/simonwagner/mergepbx/
It is a script that will help you to merge Xcode project files correctly. Note that it is still alpha.
Disclaimer: I am the author of mergepbx.
The best way I have found is to instruct Git to treat the .pbxproj file as a binary. This prevents messy merges.
Add this to your .gitatributes file:
*.pbxproj -crlf -diff -merge
To compare two Xcode projects open open FileMerge (open xcode and select Xcode (from the manu pane) --> Open developer tools --> FileMerge).
now click "left" button and open xcode project main directory.
click "right" button and open xcode project main directory to compare.
Now click "merge" button!
Thats it!
Another option to consider which may help to reduce the number of times you experience the problem. To explain, I'll call the branch that team members' branches come from the "develop" branch.
Have a convention in your team that when the project file is modified, the changes (along with any other changes required to ensure the build integrity) are committed in a separate commit. That commit is then cherry picked onto the develop branch. Other team members who plan to modify the project file in their branch can then either cherry pick into their branch or rebase their branch on the latest develop. This approach requires communication across the team and some discipline. As I said, it won't always be possible; on some projects it might help a lot and on some projects it might not.
I wish to utilize the new gated check-in function of TFS 2010.
I have about 10 solutions, that all share as a dependency a proprietary shared-code library.
My structure is:
TeamProj/SharedCode
TeamProj/Proj1
TeamProj/Proj2
TeamProj/Proj3
........
The question I have is, how can I set-off an integration of ALL projects that have the SharedCode project as a dependency?
It's possible someone can make breaking changes, and not be aware of it until one of the other projects is opened/built manually.
I want to only trigger a big integration build when check-ins are made against the SharedCode folder.
The problem is, if I map the source-paths required to actually run the builds for the other projects, check-ins are picked-up automatically against all THOSE projects too.
How can I have a gated-checkin controlled folder that is independent to the source actually required to run a build?
Cheers,
Dave
If I understand right, you want to create a Build Definition as gated checkin that builds
TeamProj/Proj1, TeamProj/Proj2, TeamProj/Proj3 when any source file in TeamProj/SharedCode is changed?
In this case, one solution that comes to my mind is the following:
Create the build definition with only source folder TeamProj/SharedCode.
Change the build template to do a TFS GET for the other folders
Change the build template to build all the three solutions Proj{1,2,3}, not the SharedCode solution.
Is this what you want?
So I have a CommonAssemblyInfo.cs linked into all the projects in my solution and is dynamically generated by my rake/albacore scripts which is not checked into source control.
I also have a CommonAssemblyInfo.cs.local for use when there is no ruby available, mainly to be used by devs.
Is it possible to have a msbuild task or something that runs before any of the other project compilation that will copy CommonAssemblyInfo.cs.local to CommonAssemblyInfo.cs before trying to compile my solution? I hate having to have a command you have to just know about and type in order to open and buidl the solution in Visual Studio.
UPDATE
So I ended up using a batch file as a solution wide pre-build event as described here: Solution-wide pre-build event?, it checks to see if CommonAssemblyInfo.cs exists and if not copies CommonAssemblyInfo.cs.local to CommonAssemblyInfo.cs just using a simple batch file.
This is the solution I ended up with.
I have each project in the solution link to a CommonAssemblyInfo.cs which is automagically generated for me by my build scripts (rake + albacore).
Since I cannot check CommonAssemblyInfo.cs into source control, I create a CommonAssemblyInfo.cs.local.
Simple solution: create go.bat which copies CommonAssemblyInfo.cs.local to CommonAssemblyInfo.cs that devs must run the first time they check out the project before opening the solution in VS.
For purely political reasons, if I did this people would have had hissy fits about me doing "nonstandard" things. Complex solution follows:
I created a project in the solution called PreBuild which every project in the solution depends on. This forces the build order to be such that this project is built first. This project contains a pre-build event which calls the following batch file:
echo verifying CommonVersionInfo.cs exists
cd
IF NOT EXIST ..\..\..\CommonAssemblyInfo.cs COPY ..\..\..\CommonAssemblyInfo.cs.local ..\..\..\CommonAssemblyInfo.cs
So now any developers who choose to keep their heads in the sand may checkout the project and blissfully open it up in VS unaware that any build scripts exist at all.
Are you talking about compilation in the VS IDE, or compilation through team build? If you are talking about team build, then you can use the "AfterGet" event as a place to use the standard "copy" msbuild task. If you are talking about the VS IDE, then you can still use the "copy" msbuild task.