[M3devel] [M3commit] log messages for committed changes

[Tony Hosking]

For M3 system development tools like m3cgcat m3cggen, standalone is  
generally best.  True, most users don't need to ship those tools.

On 26 Jun 2009, at 12:40, Jay wrote:

>
> I was thinking of starting an email thread on this.
>
>
> I believe the reasons to make things standalone are:
>
>  - unshipped built-global tools run during the build, such as  
> m3bundle, stub generators, PklFonts, etc.
>    I think these could be addressed but it'd take some work.
>
>
>  - "Tony's convenience", still being discussed.
>    A think this was a stronger case prior to -rpath where having  
> "separate runnable backups"
>    was more difficult. Or perhaps still since -rpath isn't yet  
> everywhere, AMD64_DARWIN in particular.
>    Personally when I revert to a backup I copy it back to the real  
> place, sometimes
>    with an entire package store,
>    but it is reasonable to not have to do that, and even reasonable  
> to reduce it to one file
>    instead of roughly three in two directories.
>    This would really only apple to cm3 and m3cgcat. For it to  
> include m3cggen would
>    definitely be surprising.
>    It is also "nice to have" cm3 statically linked because when  
> cross building to a new
>    platform, you don't have to get shared libraries working before  
> running cm3. But
>    you could toggle that for this scenario.
>
>    I had thought there was also a requirement around bootstrapping  
> from an older
>    build, where old cm3 can't build new m3core/libm3, but I don't  
> see that now.
>
>  - inability on some platforms to ship in use files, could be worked  
> around, but
>    partly related to previous, and more than that; in particular cm3  
> shouldn't ship
>    m3core.so/libm3.so that it uses, if you intend to run that cm3  
> again
>
>
>  - possibly so they can be redistributed with fewer files
>    This is the typical reason in the larger world for reducing  
> dynamic linking,
>      as well to be independent of changes to those files.
>    But I don't think "we" intend that to happen for "our" stuff.
>     And I think we intend for now to always ship everything together,
>     so versioning and compatibility can be ignored. I think.
>    There are still a few sprinkled standalones, like in games.
>      Which is why I was going to start email.
>    If someone really wanted to copy solitaire around without  
> installing its dependencies,
>    rebuild it from source?
>
>
>  - cminstall, because it runs so early
>    Though this could be addressed via -rpath = $ORIGIN and putting
>    the .so files it needs next to it, and not duplicating them.
>
>
> The reason to make things not standalone is several efficiency gains.
> You share the code in memory, you share it on disk, you don't copy  
> it around
> as many times, locally or over the network. The savings are  
> generally pretty large.
>
>
>  - Jay
>
>
> ________________________________
>> Date: Fri, 26 Jun 2009 12:24:47 -0400
>> From: rcolebur at scires.com
>> To: m3commit at elegosoft.com; m3devel at elegosoft.com
>> Subject: [M3commit] log messages for committed changes
>>
>>
>>
>>
>>
>>
>>
>> Hey, I've seen several of these type messages (see below). My  
>> question is "WHY"? Just to state that it doesn't need to be  
>> standalone begs the question why was it made standalone in the  
>> first place and what is the reason why it no longer needs to be  
>> that way.
>>
>>
>>
>> Maybe this is part of a larger rant on my part, but when folks  
>> commit changes, I would encourage everyone to provide some  
>> rationale and detail in the log message.
>>
>>
>>
>> There are few people like Olaf and Tony that have enough  
>> perspective with the whole system to be able to look at the details  
>> of what was changed and try to reverse something that goes against  
>> core principals or that will cause problems elsewhere. For the rest  
>> of us, and for documentation of the system evolution, it is  
>> important that the log messages be as detailed as possible, at  
>> least to give the rationale why a change is being made. I know  
>> documentation is not glamorous and doesn't directly affect the  
>> code, but it is nonetheless important, and if done well can be a  
>> real benefit.
>>
>>
>>
>> Thanks for listening. I'll step down off my soapbox now.
>>
>>
>>
>> Regards,
>>
>> Randy Coleburn
>>
>>
>>>>> Jay Krell 6/26/2009 10:12 AM>>>
>> CVSROOT:/usr/cvs
>> Changes by:jkrell at birch.09/06/26 10:12:42
>>
>> Modified files:
>> cm3/m3-sys/m3cgcat/src/: m3makefile
>>
>> Log message:
>> This doesn't need to be standalone.
>>
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090626/b74eb086/attachment-0002.html>