A new repo for objc-debug-tools

[Andrew Jeffery]

Hi Vijay,

First up, can you please change your mail client configuration to use a quote
marker that isn't a double space? It makes it quite hard to parse your emails.
'> ' is a fairly standard choice and breaks in this pattern catch the eye easily
(i.e. I can actually find where you've replied).

On Sat, 24 Aug 2019, at 09:02, Vijay Khemka wrote:
> 
> 
> On 8/20/19, 5:16 PM, "Andrew Jeffery" <andrew at aj.id.au> wrote:
> 
>     
>     
>     On Wed, 21 Aug 2019, at 06:22, Vijay Khemka wrote:
>     >  
>     > Hi Brad,
>     > 
>     > Can you please create a new repo for obmc-debug-tools. I have put 
> a 
>     > simple document here and will elaborate later.
>     > 
>     > 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.openbmc-2Dproject.xyz_-23_c_openbmc_docs_-2B_24591_&d=DwIBAg&c=5VD0RTtNlTh3ycd41b3MUw&r=v9MU0Ki9pWnTXCWwjHPVgpnCR80vXkkcrIaqU7USl5g&m=6z2u4EUj64SDPW7olBwN2br_N9k1c_r4MLozFVqSD9E&s=GIVGeSr8_0FCPynnfun2IgbxjysQyF4bncnGOF_CyX4&e= 
>     
>     The documentation suggests these tools are primarily for debugging
>     purposes. This wasn't clear to me previously - I now think we should
>     just host them in the openbmc-tools repo where we already host a
>     bunch of other scripts for debugging. If you want to install them in the
>     image then we just write the recipes necessary.


>
> I see in openbmc-tools repo, there are separate directories for individual user.

Not to be too argumentative here, but I don't see the issues you've outlined
above as a compelling reason to create a new repository. My expectation of
the complexity of these debug tools is on the order of a single source file. If
this isn't the case, then please correct me, but I'd also be curious as to why
they are more complex than that.

Anyway, some history: The one-directory-per-person was mainly an artefact
of how the repository came into existence, which involved a subtree-merge of
several other people's repositories. To contain the mess I simply sucked each
repo into a directory named after their github ID. The intent is, when someone
has time, to analyse what we've got and restructure the repository along the
lines of purposes for the tools. Maybe that time has come.

> And it contains only scripts. I would like this debug tools to be buildable via
> cmake 

The fact that it currently contains only scripts doesn't mean that it can't
contain the source for any ahead-of-time compiled tools. In fact, the
statement that it contains only scripts isn't actually true: AMI have submitted
a couple of tools they find useful which are written in C and built with
autotools[1][2]. There's no reason we can't accommodate CMake (it's not my
preference of build system, but that only becomes an issue when I'm trying
to fix bugs in CMake-based projects :)).

> and we shouldn't download whole repo if we need only these tools. 

I don't follow the line of reasoning for this statement. We download the repo for
the Linux kernel but maybe only build a 10th of that; it seems odd to make the
argument that we shouldn't grab the whole openbmc-tools repo when it currently
weighs 812KiB. If the haphazard structure is the concern then this should be
addressed by my first point above, and the only minor issue is making sure any
bitbake recipes deal with the directory structure appropriately.

> Would prefer to have a separate repo for all tools which can be useful.

If we're collecting useless tools we should probably stop that :)

Andrew

[1] https://github.com/openbmc/openbmc-tools/tree/master/hongweiz/adcapp
[2] https://github.com/openbmc/openbmc-tools/tree/master/hongweiz/pwmtachtool