All of lore.kernel.org
 help / color / mirror / Atom feed
* Run unit-test during development
@ 2021-12-13  8:46 Deng Tyler
  2021-12-13 16:00 ` Patrick Williams
  0 siblings, 1 reply; 6+ messages in thread
From: Deng Tyler @ 2021-12-13  8:46 UTC (permalink / raw)
  To: OpenBMC Maillist

[-- Attachment #1: Type: text/plain, Size: 127 bytes --]

Hi All:
    Is there any easier way to run unit-test during development instead of
running run-unit-test-docker.sh?

BR,
Tyler

[-- Attachment #2: Type: text/html, Size: 196 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Run unit-test during development
  2021-12-13  8:46 Run unit-test during development Deng Tyler
@ 2021-12-13 16:00 ` Patrick Williams
  2021-12-16  5:53   ` Deng Tyler
  0 siblings, 1 reply; 6+ messages in thread
From: Patrick Williams @ 2021-12-13 16:00 UTC (permalink / raw)
  To: Deng Tyler; +Cc: OpenBMC Maillist

[-- Attachment #1: Type: text/plain, Size: 2254 bytes --]

On Mon, Dec 13, 2021 at 04:46:13PM +0800, Deng Tyler wrote:
> Hi All:
>     Is there any easier way to run unit-test during development instead of
> running run-unit-test-docker.sh?

If the repository is built using autotools or CMake there probably aren't a lot
of other options.  Yocto has something called 'ptest' which would, in theory,
allow the package to build test-cases and deploy them onto the hardware to run
the unit tests.  We don't have many repositories configured to support ptest
though.

Any repository that is building using Meson should be able to run the unit tests
on a typical Linux development box.  Some of them have not fully implemented
this though.  What you want to look for is if the repository has a 'meson.build'
and 'subprojects' subdirectory that contains a number of 'foo.wrap' files.  If
it has this, you can probably build the repository outside of
`run-unit-test-docker.sh` or a Yocto OE-SDK environment.

In that case, simply `meson builddir && ninja -C builddir test`.

If you come across a repository that supports Meson (meson.build file) but
doesn't have correct wrap files, those can be added fairly easily.  I suspect
you could use these repositories as a reference:

```
$ ls */subprojects/phosphor-logging.wrap
dbus-sensors/subprojects/phosphor-logging.wrap
google-misc/subprojects/phosphor-logging.wrap
openpower-debug-collector/subprojects/phosphor-logging.wrap
openpower-occ-control/subprojects/phosphor-logging.wrap
openpower-vpd-parser/subprojects/phosphor-logging.wrap
phosphor-bmc-code-mgmt/subprojects/phosphor-logging.wrap
phosphor-certificate-manager/subprojects/phosphor-logging.wrap
phosphor-debug-collector/subprojects/phosphor-logging.wrap
phosphor-health-monitor/subprojects/phosphor-logging.wrap
phosphor-led-manager/subprojects/phosphor-logging.wrap
phosphor-networkd/subprojects/phosphor-logging.wrap
phosphor-objmgr/subprojects/phosphor-logging.wrap
phosphor-sel-logger/subprojects/phosphor-logging.wrap
phosphor-virtual-sensor/subprojects/phosphor-logging.wrap
phosphor-watchdog/subprojects/phosphor-logging.wrap
service-config-manager/subprojects/phosphor-logging.wrap
telemetry/subprojects/phosphor-logging.wrap
```

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Run unit-test during development
  2021-12-13 16:00 ` Patrick Williams
@ 2021-12-16  5:53   ` Deng Tyler
  2021-12-16 17:12     ` Patrick Williams
  0 siblings, 1 reply; 6+ messages in thread
From: Deng Tyler @ 2021-12-16  5:53 UTC (permalink / raw)
  To: Patrick Williams; +Cc: OpenBMC Maillist

[-- Attachment #1: Type: text/plain, Size: 2936 bytes --]

Hi Patrick:
    Thank for your kind reply and that's really helpful. I am trying to
figure out the meson subprojects system but still encounter lot of barrier.
I run unt test using command "meson buiildir && ninja -C builddir test" in
my development environment but never work. Could you help to cite an
example in current openbmc repository? Do openbmc contributor run unit test
by meson subprojects or run-unit-test-docker.sh when they are developing?

Tyler

Patrick Williams <patrick@stwcx.xyz> 於 2021年12月14日 週二 上午12:00寫道:

> On Mon, Dec 13, 2021 at 04:46:13PM +0800, Deng Tyler wrote:
> > Hi All:
> >     Is there any easier way to run unit-test during development instead
> of
> > running run-unit-test-docker.sh?
>
> If the repository is built using autotools or CMake there probably aren't
> a lot
> of other options.  Yocto has something called 'ptest' which would, in
> theory,
> allow the package to build test-cases and deploy them onto the hardware to
> run
> the unit tests.  We don't have many repositories configured to support
> ptest
> though.
>
> Any repository that is building using Meson should be able to run the unit
> tests
> on a typical Linux development box.  Some of them have not fully
> implemented
> this though.  What you want to look for is if the repository has a
> 'meson.build'
> and 'subprojects' subdirectory that contains a number of 'foo.wrap'
> files.  If
> it has this, you can probably build the repository outside of
> `run-unit-test-docker.sh` or a Yocto OE-SDK environment.
>
> In that case, simply `meson builddir && ninja -C builddir test`.
>
> If you come across a repository that supports Meson (meson.build file) but
> doesn't have correct wrap files, those can be added fairly easily.  I
> suspect
> you could use these repositories as a reference:
>
> ```
> $ ls */subprojects/phosphor-logging.wrap
> dbus-sensors/subprojects/phosphor-logging.wrap
> google-misc/subprojects/phosphor-logging.wrap
> openpower-debug-collector/subprojects/phosphor-logging.wrap
> openpower-occ-control/subprojects/phosphor-logging.wrap
> openpower-vpd-parser/subprojects/phosphor-logging.wrap
> phosphor-bmc-code-mgmt/subprojects/phosphor-logging.wrap
> phosphor-certificate-manager/subprojects/phosphor-logging.wrap
> phosphor-debug-collector/subprojects/phosphor-logging.wrap
> phosphor-health-monitor/subprojects/phosphor-logging.wrap
> phosphor-led-manager/subprojects/phosphor-logging.wrap
> phosphor-networkd/subprojects/phosphor-logging.wrap
> phosphor-objmgr/subprojects/phosphor-logging.wrap
> phosphor-sel-logger/subprojects/phosphor-logging.wrap
> phosphor-virtual-sensor/subprojects/phosphor-logging.wrap
> phosphor-watchdog/subprojects/phosphor-logging.wrap
> service-config-manager/subprojects/phosphor-logging.wrap
> telemetry/subprojects/phosphor-logging.wrap
> ```
>
> --
> Patrick Williams
>

[-- Attachment #2: Type: text/html, Size: 3399 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Run unit-test during development
  2021-12-16  5:53   ` Deng Tyler
@ 2021-12-16 17:12     ` Patrick Williams
  2021-12-17  2:36       ` Deng Tyler
  0 siblings, 1 reply; 6+ messages in thread
From: Patrick Williams @ 2021-12-16 17:12 UTC (permalink / raw)
  To: Deng Tyler; +Cc: OpenBMC Maillist

[-- Attachment #1: Type: text/plain, Size: 1597 bytes --]

On Thu, Dec 16, 2021 at 01:53:41PM +0800, Deng Tyler wrote:
> Hi Patrick:
>     Thank for your kind reply and that's really helpful. I am trying to
> figure out the meson subprojects system but still encounter lot of barrier.
> I run unt test using command "meson buiildir && ninja -C builddir test" in
> my development environment but never work. Could you help to cite an
> example in current openbmc repository? Do openbmc contributor run unit test
> by meson subprojects or run-unit-test-docker.sh when they are developing?

I can't really comment on what other people do, but I can tell you what I do.

1. If the repository supports Meson, I always attempt to build / test using
   standalone support (ie. meson subprojects).

2. If 'meson subprojects' doesn't seem to work, I fix it to make it work.

3. If the repository is anything else and it isn't too much effort, I try to
   port it to meson.

4. When all else fails I use 'run-unit-test-docker.sh'.  I often execute it with
   an alias I have: `NO_FORMAT_CODE=1 lf-ut`[1].

---

Do you have examples of meson+ninja failing?  I'm fairly certain it works fine
for almost every repository I'm listed as a maintainer on.  I've also used it
(or fixed it) fairly recently for: bmcweb, phosphor-logging, and
phosphor-certificate-manager.

Maybe you can point to what failure you're seeing in that case as well (you
can upload a log to gist.github.com )?



1. https://github.com/williamspatrick/dotfiles/blob/fb542abf99c944051544990f69a6d20c82d2a904/env/30_linux/lfopenbmc.zsh#L76

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Run unit-test during development
  2021-12-16 17:12     ` Patrick Williams
@ 2021-12-17  2:36       ` Deng Tyler
  2021-12-17  2:39         ` Andrew Jeffery
  0 siblings, 1 reply; 6+ messages in thread
From: Deng Tyler @ 2021-12-17  2:36 UTC (permalink / raw)
  To: Patrick Williams; +Cc: OpenBMC Maillist

[-- Attachment #1: Type: text/plain, Size: 3816 bytes --]

Hi Patrick:
    I try to build and run unit test repository which support meson such as
phosphor-logging and phosphor-network. There is dependency issue while
building them and I wonder it is a bug or my environment issue.
/openbmc/phosphor-logging$ meson builddir && ninja -C builddir test
The Meson build system
Version: 0.59.2
Source dir:  /openbmc/phosphor-logging
Build dir:  /openbmc/phosphor-logging/builddir
Build type: native build
Project name: phosphor-logging
Project version: 1.0.0
C++ compiler for the host machine: c++ (gcc 7.5.0 "c++ (Ubuntu
7.5.0-3ubuntu1~18.04) 7.5.0")
C++ linker for the host machine: c++ ld.bfd 2.30
Host machine cpu family: x86_64
Host machine cpu: x86_64
Program python3 found: YES (/usr/bin/python3)
Found pkg-config: /usr/bin/pkg-config (0.29.1)
Run-time dependency systemd found: YES 237
Found CMake: /usr/bin/cmake (3.10.2)
Run-time dependency sdbusplus found: NO (tried pkgconfig and cmake)
Cloning into 'sdbusplus'...
remote: Enumerating objects: 3559, done.
remote: Counting objects: 100% (609/609), done.
remote: Compressing objects: 100% (384/384), done.
remote: Total 3559 (delta 346), reused 403 (delta 162), pack-reused 2950
Receiving objects: 100% (3559/3559), 891.70 KiB | 7.37 MiB/s, done.
Resolving deltas: 100% (2289/2289), done.

Executing subproject sdbusplus

sdbusplus| Project name: sdbusplus
sdbusplus| Project version: 1.0.0
sdbusplus| C compiler for the host machine: cc (gcc 7.5.0 "cc (Ubuntu
7.5.0-3ubuntu1~18.04) 7.5.0")
sdbusplus| C linker for the host machine: cc ld.bfd 2.30
sdbusplus| C++ compiler for the host machine: c++ (gcc 7.5.0 "c++ (Ubuntu
7.5.0-3ubuntu1~18.04) 7.5.0")
sdbusplus| C++ linker for the host machine: c++ ld.bfd 2.30
sdbusplus| Run-time dependency libsystemd found: NO (tried pkgconfig and
cmake)

subprojects/sdbusplus/meson.build:14:0: ERROR: Dependency "libsystemd" not
found, tried pkgconfig and cmake

A full log can be found at
 /openbmc/phosphor-logging/builddir/meson-logs/meson-log.txt

Patrick Williams <patrick@stwcx.xyz> 於 2021年12月17日 週五 上午1:12寫道:

> On Thu, Dec 16, 2021 at 01:53:41PM +0800, Deng Tyler wrote:
> > Hi Patrick:
> >     Thank for your kind reply and that's really helpful. I am trying to
> > figure out the meson subprojects system but still encounter lot of
> barrier.
> > I run unt test using command "meson buiildir && ninja -C builddir test"
> in
> > my development environment but never work. Could you help to cite an
> > example in current openbmc repository? Do openbmc contributor run unit
> test
> > by meson subprojects or run-unit-test-docker.sh when they are developing?
>
> I can't really comment on what other people do, but I can tell you what I
> do.
>
> 1. If the repository supports Meson, I always attempt to build / test using
>    standalone support (ie. meson subprojects).
>
> 2. If 'meson subprojects' doesn't seem to work, I fix it to make it work.
>
> 3. If the repository is anything else and it isn't too much effort, I try
> to
>    port it to meson.
>
> 4. When all else fails I use 'run-unit-test-docker.sh'.  I often execute
> it with
>    an alias I have: `NO_FORMAT_CODE=1 lf-ut`[1].
>
> ---
>
> Do you have examples of meson+ninja failing?  I'm fairly certain it works
> fine
> for almost every repository I'm listed as a maintainer on.  I've also used
> it
> (or fixed it) fairly recently for: bmcweb, phosphor-logging, and
> phosphor-certificate-manager.
>
> Maybe you can point to what failure you're seeing in that case as well (you
> can upload a log to gist.github.com )?
>
>
>
> 1.
> https://github.com/williamspatrick/dotfiles/blob/fb542abf99c944051544990f69a6d20c82d2a904/env/30_linux/lfopenbmc.zsh#L76
>
> --
> Patrick Williams
>

[-- Attachment #2: Type: text/html, Size: 4634 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Run unit-test during development
  2021-12-17  2:36       ` Deng Tyler
@ 2021-12-17  2:39         ` Andrew Jeffery
  0 siblings, 0 replies; 6+ messages in thread
From: Andrew Jeffery @ 2021-12-17  2:39 UTC (permalink / raw)
  To: Deng Tyler, Patrick Williams; +Cc: OpenBMC Maillist

On Fri, 17 Dec 2021, at 13:06, Deng Tyler wrote:
> Hi Patrick:
>     I try to build and run unit test repository which support meson such as
> phosphor-logging and phosphor-network. There is dependency issue while
> building them and I wonder it is a bug or my environment issue.
> /openbmc/phosphor-logging$ meson builddir && ninja -C builddir test

...

>
> subprojects/sdbusplus/meson.build:14:0: ERROR: Dependency "libsystemd" not
> found, tried pkgconfig and cmake

You need to run:

sudo apt install libsystemd-dev

Andrew

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2021-12-17  2:46 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-12-13  8:46 Run unit-test during development Deng Tyler
2021-12-13 16:00 ` Patrick Williams
2021-12-16  5:53   ` Deng Tyler
2021-12-16 17:12     ` Patrick Williams
2021-12-17  2:36       ` Deng Tyler
2021-12-17  2:39         ` Andrew Jeffery

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.