Disclaimer

The content of this blog is my personal opinion only. Although I am an employee - currently of Imagination Technologies's MIPS group, in the past of other companies such as Intellectual Ventures, Intel, AMD, Motorola, and Gould - I reveal this only so that the reader may account for any possible bias I may have towards my employer's products. The statements I make here in no way represent my employer's position, nor am I authorized to speak on behalf of my employer. In fact, this posting may not even represent my personal opinion, since occasionally I play devil's advocate.

See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.

Tuesday, June 19, 2012

Monolithics and Makefiles

I think that one of the reasons why some people write big monolithic programs with too many classes and functions and just plain stuff in the same headers and .c/.cpp files is that they do not have goopd dynamic Make tools. They get the Makefile working, and then don't touch it, since touching it would require editing by hand.


Multihomed workspaces and repos

I often find myself wanting a "multihiomed" workspace or repo:

E.g. a workspace where I push to one or more places regularly.

E.g. I may push to my personal backup or tracking repo.
But occasionally I need to push to a project master.

This becomes complicated when a meta-project is composed of several subrepos - e.g. the main project source, but also source for libraries and tools.  Then I want to push the whiole meta-project to the meta-project-repo, the main project (which is a subrepo of the meta-project) to the main project master repo, and the tools and libraries sometimes to the meta-project-repo, and sometimes to their respective master repos.

I can do this by hand, if I remember the names.

But I want to create nice default behavior.  Like "push to my backup or m,eta-repo".
And "release all of my changes to rtheir respective providers".

Of course, the respective providers may themselves have flows.

--

I don't see a standard way in hg.

This is partly why I create the CVS.1 CVS.2 ... dirs, long ago.

For now, I am manually recording the multiple homes in files such as meta-repo/subrepo/hg-paths.

Trouyble is, I may not be allowed to asdd stuff like that to meta-repo/subrepo, since that tree belongs to thwe provider.


So I have had to add the metadata about multihoming elsewhere, e.g.
meta-repo/subrepo/hg-paths--for--subrepo.
(I would call it meta-repo/subrepo/hg-paths:subrepo), except I am warned about Windows not liking colons.



Minor BKM: -comment_knob

I find it convenient to give certain programs a command line option that is just a placeholder, which ignoeres its string argument.  Just to hold comments.

Especially useful in a test, so you can say

   command -comment_knob 'expect failure' -illegal-option ...