[M3devel] possible cygwin createprocess/fork cost measurements..

[Olaf Wagner]

Quoting Jay <jayk123 at hotmail.com>:

> Olaf,

> The branch advise helps, but as well, I mean "directory   
> structure"-wise, experimental, possibly throw away work, possibly   
> interesting to keep around for future measuring, but not in any   
> default build. Perhaps that is what you meant -- perhaps a private   
> branch is ok for "personal history" even if it ends up being deleted  
>  and never going to another branch? Kind of an abuse, but useful,  
> and  maybe affordable? You know, rather than me saving away backups  
> every  hour in case I want to go back to an older version of what  
> will  still actually be thrown away?

That's a very common use for branches and exactly what is recommened
in the CM3 SCM guidelines, IIRC.
Currently in CM3 branches are used for three purposes:

  1. vendor branches for imports of third party software (like gcc)
  2. feature branches for experimental new development (which may or
     may not be merged into any release or the main line)
  3. release engineering branches for the (very infrequent) official
     releases (last used for 5.4.0, IIRC)

As almost all work is currently done on the main line, I'd like
to encourage the use of branches for more experimental work, so
as not to disturb maintenance work. I even suggested to restrict
commits to the main line and allow only branch commits for
development as a counter measure to loosing control of the
various work, but am not convinced myself that it is worth the
effort, and others didn't seem to like it very much, too.

I don't think anybody would object if you commit more experimental
or radical changes to a branch.

> Or I could just use my private SVN.  Yep. I did that. I'm wondering  
> about making it world readable or  somehow sharing it out. It's not  
> chock full of stuff, but, of  course, I get to decide what I am  
> allowed to checkin. :)

That's of course another option; but I'd rather like to keep
the resources centralized. What really is needed is more integration
and ease of use, and not more diversion.

> It really bugs me 1) that there aren't more .dlls/.libs for use   
> in-proc instead of shelling out to command lines 2) the related   
> licensing unclarity. cm3cg and as really should not cost a process,   
> the compiler should output .objs directly.

Have you had a look at System.ExecuteList and q_exec? It really is
a pure M3-based implementation of the most needed shell feataures
like i/o redirection, command lists, and pipes. If you only use
these features, they will run independently of the underlying
target platform.

If will of course not help with the issue of the separated
compiler backend. Integrated backends can be developped independently
of gcc though.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194