Minor query regarding no-libfdt use case

[onkarharsh]

https://github.com/devicetree-org/lopper/blob/master/lopper/__main__.py#L234

There is a user argument --no-libfdt. Just curious to know under what circumstances user would like to exercise this option. I see that LopperDT class is not as enriched as LopperFDT. Any future plans?

[zeddii]

The work was done to support integration with Zephyr and other build systems that don't use libfdt, but do support parsing with other python-only libraries.

It is also in place to support build systems that don't have the capability of c-bindings to python (and hence dtc/libfdt) or on target execution of python only (python is preferable in some cases to the complexity of native / c bindings to python).

For the most part, the functionality is similar but has largely only been tested for those specific code paths.

There's no reason it can't have the same feature set as the libfdt backed use cases, but the current DT parser used for non-libfdt is more strict and fails many of the inputs that dtc allows (and it has scheme requirements), so it is less extenstively used at the moment.

As more scheme support is added directly to lopper, this parser becomes more viable for feature parity.

[onkarharsh]

Thanks @zeddii for clarification.

I stumbled across this part of code while running sphinx to create API docs for the assists. There are few assists like lopper_lib which imports "Lopper" variable from "lopper" package. "Lopper" variable is defined under main() function based on a condition (https://github.com/devicetree-org/lopper/blob/master/lopper/__main__.py#L234)) and is not part of lopper package directly (init.py). Therefore. Sphinx is not able to find the "Lopper" variable even though the lopper package is added to the PATH. I could work it around by hardcoding the Lopper variable within the lopper package (i.e. in init.py).

As it is just about documentation, it is not bothering me much. I just feel that it's not correct to leave a package variable undefined when main() is not called. We should declare Lopper variable with some default value to avoid such errors. Would like to know your opinion on this.

[zeddii]

When I was adding the support for the two dt input mechanisms, I found that it wasn't possible to assign that value a default and then be able to later override it based on the command line option.

That could have been an idiosyncrasy of the python version I was using at the time.

Due to the way the lopper modules are structured, there's some interplay and initialization order that makes it tricky to globally override that variable and have other imports work without circular references. That's how the implementation landed as it currently stands.

That being said, I can give the global Lopper variable a default as such:

diff --git a/lopper/init.py b/lopper/init.py
index 4155db1..57ba468 100644
--- a/lopper/init.py
+++ b/lopper/init.py
@@ -19,6 +19,7 @@ import tempfile
from collections import OrderedDict

from lopper.fmt import LopperFmt
+from lopper.fdt import LopperFDT

from lopper.tree import LopperNode, LopperTree, LopperTreePrinter, LopperProp
import lopper.tree
@@ -34,6 +35,10 @@ except Exception as e:
print( f"[WARNING]: cant load yaml, disabling support: {e}" )
yaml_support = False

+# Default processing type
+Lopper = LopperFDT
+lopper.tree.Lopper = Lopper
+
@contextlib.contextmanager
def stdoutIO(stdout=None):
old = sys.stdout

And everything still appears to work. I've added that to my local commits and will let it soak for a few days.