An unfortunate series of roadblocks in a multiproject configuration

I have some issues using a multi-project structure for my project. In general, I have a root CMakeLists.txt with common configuration, from which I add subdirectories where my subprojects live. These subprojects are one executable (the main program) and a custom arduino library. The library is not packaged, and is developed as a part of the project.
I've hit a number of issues, worked around a couple, and finally hit a roadblock. These are the problems I hit:

get_board_id fails if called before a project() call, preventing it from being used in the root file without creating a fake project with an `Unknown CMake command" fault.

/home/jarl/.local/share/JetBrains/Toolbox/apps/CLion/ch-0/183.4139.25/bin/cmake/linux/bin/cmake -DCMAKE_BUILD_TYPE=Debug -G "CodeBlocks - Unix Makefiles" /home/jarl/Programming/Plantbuddy
CMake Error at CMakeLists.txt:11 (get_board_id):
  Unknown CMake command "get_board_id".

-- Configuring incomplete, errors occurred!

[Finished]

find_arduino_library fails if called before an add_arduino_executable or add_arduino_library, preventing it from being used in the root file. Instead, it must be used in a subdirectory, making it unclear which libraries are available to which targets, and in what order to load them.

/home/jarl/.local/share/JetBrains/Toolbox/apps/CLion/ch-0/183.4139.25/bin/cmake/linux/bin/cmake -DCMAKE_BUILD_TYPE=Debug -G "CodeBlocks - Unix Makefiles" /home/jarl/Programming/Plantbuddy
-- The C compiler identification is GNU 4.9.2
-- The CXX compiler identification is GNU 4.9.2
-- Arduino SDK version 1.8.1: /opt/arduino-1.8.1
-- Determined Platform Header: /opt/arduino-1.8.1/hardware/arduino/avr/cores/arduino/Arduino.h
-- Arduino SDK version 1.8.1: /opt/arduino-1.8.1
-- Determined Platform Header: /opt/arduino-1.8.1/hardware/arduino/avr/cores/arduino/Arduino.h
-- Check for working C compiler: /opt/arduino-1.8.1/hardware/tools/avr/bin/avr-gcc
-- Check for working C compiler: /opt/arduino-1.8.1/hardware/tools/avr/bin/avr-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Arduino SDK version 1.8.1: /opt/arduino-1.8.1
-- Determined Platform Header: /opt/arduino-1.8.1/hardware/arduino/avr/cores/arduino/Arduino.h
-- Check for working CXX compiler: /opt/arduino-1.8.1/hardware/tools/avr/bin/avr-g++
-- Check for working CXX compiler: /opt/arduino-1.8.1/hardware/tools/avr/bin/avr-g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at cmake/Platform/Targets/ArduinoCMakeLibraryTarget.cmake:60 (get_target_property):
  get_target_property() called with non-existent target "uno_core_lib".
Call Stack (most recent call first):
  cmake/Platform/Targets/PlatformLibraryTarget.cmake:63 (_link_arduino_cmake_library)
  cmake/Platform/Targets/ArduinoLibraryTarget.cmake:29 (link_platform_library)
  cmake/Platform/Libraries/LibrariesFinder.cmake:77 (add_arduino_library)
  CMakeLists.txt:17 (find_arduino_library)

CMake Error at cmake/Platform/Targets/ArduinoCMakeLibraryTarget.cmake:60 (get_target_property):
  get_target_property() called with non-existent target "uno_core_lib".
Call Stack (most recent call first):
  cmake/Platform/Targets/PlatformLibraryTarget.cmake:63 (_link_arduino_cmake_library)
  cmake/Platform/Targets/ArduinoLibraryTarget.cmake:29 (link_platform_library)
  cmake/Platform/Libraries/LibrariesFinder.cmake:77 (add_arduino_library)
  CMakeLists.txt:17 (find_arduino_library)

CMake Error at cmake/Platform/Targets/ArduinoLibraryTarget.cmake:66 (message):
  Core Library target doesn't exist.  This is bad and should be reported
Call Stack (most recent call first):
  CMakeLists.txt:19 (link_arduino_library)

-- Configuring incomplete, errors occurred!
See also "/home/jarl/Programming/Plantbuddy/cmake-build-debug/CMakeFiles/CMakeOutput.log".

[Finished]

add_arduino_library fails completely if _sources is omitted, preventing target_sources from being used.

/home/jarl/.local/share/JetBrains/Toolbox/apps/CLion/ch-0/183.4139.25/bin/cmake/linux/bin/cmake -DCMAKE_BUILD_TYPE=Debug -G "CodeBlocks - Unix Makefiles" /home/jarl/Programming/Plantbuddy
-- Arduino SDK version 1.8.1: /opt/arduino-1.8.1
-- Determined Platform Header: /opt/arduino-1.8.1/hardware/arduino/avr/cores/arduino/Arduino.h
-- Arduino SDK version 1.8.1: /opt/arduino-1.8.1
-- Determined Platform Header: /opt/arduino-1.8.1/hardware/arduino/avr/cores/arduino/Arduino.h
-- Arduino SDK version 1.8.1: /opt/arduino-1.8.1
-- Determined Platform Header: /opt/arduino-1.8.1/hardware/arduino/avr/cores/arduino/Arduino.h
CMake Error at cmake/Platform/Utilities/CMakeArgumentsUtils.cmake:21 (list):
  list GET given empty list
Call Stack (most recent call first):
  cmake/Platform/Utilities/CMakeArgumentsUtils.cmake:60 (_consume_reserved_arguments)
  cmake/Platform/Targets/ArduinoLibraryTarget.cmake:11 (parse_sources_arguments)
  microui/CMakeLists.txt:3 (add_arduino_library)

CMake Error at cmake/Platform/Utilities/CMakeArgumentsUtils.cmake:23 (if):
  if given arguments:

    "IN_LIST" "_reserved_options"

  Unknown arguments specified
Call Stack (most recent call first):
  cmake/Platform/Utilities/CMakeArgumentsUtils.cmake:60 (_consume_reserved_arguments)
  cmake/Platform/Targets/ArduinoLibraryTarget.cmake:11 (parse_sources_arguments)
  microui/CMakeLists.txt:3 (add_arduino_library)

-- Configuring incomplete, errors occurred!
See also "/home/jarl/Programming/Plantbuddy/cmake-build-debug/CMakeFiles/CMakeOutput.log".

[Finished]

find_arduino_library fails once more if called after add_arduino_library with explicit source specification, with the same error as 2.

Removing the libraries altogether to continue results in find_arduino_library failing when the executable attempts to link to it, due to it not being able to find the target.

The full source for the project scaffolding is available here: https://github.com/Nihlus/plantbuddy
Each problem stage has its own branch, so they can be individually inspected. In each branch succeeding roadblock-1, the workaround has been applied. roadblock-1 can be considered the ideal setup.
Any help with this would be much appreciated. I love being able to use CMake & CLion for my arduino projects, and in single-project mode, I haven't had any issues at all.

@Nihlus Sorry for the long delay, I'm extremely busy these weeks...
As to your problems, I'll relate to each at the order they appeared:

That's just how CMake works. You shouldn't do anything before the project() call, since this is what initializes CMake itself behind the scenes, kind of.
In our case, you're trying to call a function from a framework that is actually part of a toolchain. All toolchains are read after the call to project(), or more accurately - As part of it. So if you'd think about it for a moment you'll realize you're trying to call an undefined function, which of course fails the execution of the script.
This is a somewhat expected behavior.
The find_arduino_library function attempts to link the board's CoreLib (Core Library) target to the found library target, i.e. to itself. However, the CoreLib target is only created inside the add_arduino_executable or add_arduino_library functions, since these are the ones that create the "top-level" target one would be working with.
With that being said, I agree that it's unclear why this assumption has been made, or worse - How should the Find API should be used. It's definitely a note to the project's developers to fix in future versions.
Well, this is interesting since it requires some extra knowledge about how libraries work in general C/C++ programming, not just in Arduino. Whenever there's a library without sources, i.e. without .c or .cpp files, it's called a header-only library.
Due to a user request, support for these types of libraries in the Arduino context also has been added to the framework, but currently it requires calling a different function. You can read more about it here: Header-Only Libraries
It maybe an indirect continuation of 3 if the libraries you're attempting to find are also header-only.
Everything you need to know on the subject is embedded in the link above.
Well, this is obvious, that's not how CMake should be used of course and it's considered a "user error", which probably is derived from all the errors mentioned above. There's nothing to add here.

Let me know if anything has helped you, good luck 😃

@MrPointer Thanks for getting back to me!

I was not aware of that - typically, in non-toolchain projects, I never run into this issue.
Not having this possible makes it very clunky to use, and seems very strange to me - requiring a library to link against the main executable instead of the other way around seems very backwards, and is far from expected behaviour. Not only that, but that it fails in such an explosive way.
In this case, the library is not a header-only library. It simply has no sources associated with the target at target creation time, and only get sources after a call to target_sources. This is a fundamental function of modern CMake, and not being able to use it makes using the library rather clunky. It works fine on add_arduino_executable.

At the very least, a more descriptive error message ought to be emitted.

See above, although I can try with a source file as well. It might help.

I think you've misunderstood me - if you have a look at the CMakeLists.txt file in the microui library at this point (which is header-only, due to me just using a dummy file. I'll try with sources, too), I was referring to it not linking to any other libraries, but the main executable in turn not being able to link to it. I was not referring to linking to a nonexistent library.

@Nihlus Well, as strange as it may seem - I haven't elaborated enough on each item, so please let me.

It's considered best practice to write CMake code of any form after the project() call, even on non-toolchain-based projects.
However, it's completely acceptable to have a project structure like yours, where the top-level CMakeLists.txt sets some global definitions which are later used by sub-projects - It simply requires the top-level CMake file to define a project, named as you'd like (usually NONE).
It happens to be my mistake - Too much time away from the code...
One can definitely can find a library before adding a custom/user library/executable target!
With that in mind, what currently can't be done is linking a found library to another if a custom/user target hasn't been already created. Yes, I completely agree that this is still unexpected behavior from a user's POV, and this will be fixed in the upcoming versions.
If so, this is indeed a bug which should also be fixed.
Same as above
If I understood you better this time, it seems you're trying to link the microui library target to the executable target, and it fails, right?
If so, I think it's a CMake limitation. Looking at your repo at this point, I notice that you're dividing the library target and the executable into 2 separate sub-directories. If I'm not mistaken, it means that they won't "see" each other's internals, meaning that target and variables in general won't be shared between them.
Nevertheless, I still need to verify this behavior and hopefully suggest a solution for you if indeed this is true.

@Nihlus Please update if there's anything else to this issue before I close it.


Is there an issue with how links are displayed in Dope?

Hey!
I'm running Dope as the theme for my blog. I've had the blog since Ghost 0.9 or something like that. I updated the blog to 4.0 and started rebuilding the content to work with Dope, but noticed that links to quotes such as below do not underline the whole link. The quotes are done via Markdown as I find them more consistent than using the regular editor.

The issue is also in links in paragraphs, not using Markdown, but the regular editor such as below, where some links are displayed correctly, others are half underlined and some have no underling at all

I thought this may have resulted from the blog being really old, so I transitioned to a brand new server, with a fresh install of 4.0, following the provided guide on the docs on 20.04 and copying all the old content over. And I got the same issue. In case something was an issue I fired up a second new server and did another fresh install, only coping a post from the editor to the new blog and I get the same issue. I even went so far as to just clone the repo and upload that to the server as the theme and still no luck

Hey @LegendaryPatMan, thanks for the report. This was just fixed in the latest version. You can now download the theme and install it again.

Awesome! Thank you! Is there somewhere I can donate to the project as thanks?

 We have a donations section on our "Contributing to Ghost" page which you can read more about it here 🙂


Off-season False on off-season events

Describe the bug
Displays small tag labeled off season false on events like Duel down under and battle cry
To Reproduce
Steps to reproduce the behavior:

Open events page
Select an off season event

Screenshots

Browser

OS: iOS16
Browser: Chrome

Additional context
None

Resolved as of 747200c.


Updog refactoring

Linked up the new CLI. You can now run things like:
load --only IRCC_GC PDMR PMLB --data-dir ../data-pdxfinder -k
Run  load --help or help load for detailed usage instructions


gitignore missing?

It might be worth adding a .gitignore file so that the .pyc files are not loaded to github. Something like the following?
# Byte-compiled / optimized / DLL files
__pycache__/
*.py[cod]

# backup files
*~

# C extensions
*.so

# Distribution / packaging
.Python
env/
#build/
develop-eggs/
dist/
eggs/
lib/
lib64/
parts/
sdist/
var/
*.egg-info/
.installed.cfg
*.egg

# version file
artview/version.py

# PyInstaller
#  Usually these files are written by a python script from a template
#  before PyInstaller builds the exe, so as to inject date/other infos into it.
*.manifest
*.spec

# Installer logs
pip-log.txt
pip-delete-this-directory.txt

# Unit test / coverage reports
htmlcov/
.tox/
.coverage
.cache
nosetests.xml
coverage.xml

# Translations
*.mo
*.pot

# Django stuff:
*.log

# Sphinx documentation
# docs/_build/
docs/build/doctrees/
docs/source/reference/generated/

# PyBuilder
target/

Well noticed ;o) ! As I am a totally newbie concering GitHub, I am not aware of all tips (even after reading all the "manual"). I will integrate your .gitignore, thanks !!

It's a pretty big ramp up, I learned the hard way on this one as well!


Feat: Cart Option Overlaps with Day/Night Symbol and Navigation Bar Visibility Issue

Describe the feature
The feature involves addressing two main issues:
Cart Option Overlapping with Day/Night Symbol: Currently, on the Flipkart clone project, there is an issue where the cart option overlaps with the day/night symbol. This makes it difficult for users to access the cart functionality and also obscures the visibility of the day/night symbol.
Navigation Bar Visibility: Additionally, there is a problem with the navigation bar where it is only partially visible. This obstructs the user's ability to navigate through the website effectively, as they cannot access all the navigation options.
Add ScreenShots
As you can refer this Screenshots

Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSOC'24 contributor
[X] I want to work on this issue

Hii @arghadipmanna101 ,
I would like to contribute to this issue .
Would u please assign this issue to me under GSSOC'24


[error]chrome_remote_interface__WEBPACK_IMPORTED_MODULE_5__.List is not a function

import CDP from 'chrome-remote-interface';
window.criRequest = function (options, callback) {};
void CDP.List({ port }, async (_err: unknown, list: CDPList[]) => {})

It went wrong when I used it in Electron webview..

It should be import {CDP} from 'cdp'

all right. my bad.. our project did sth on require/import


Insecure resource included

The issue pane tries to open 'http://www.w3.org/2005/01/wf/flow' which is not allowed if the page is loaded over https.

This seems to be referred to from the tracker config:
@prefix flow: <http://www.w3.org/2005/01/wf/flow#>.


AttributeError: 'NoneType' object has no attribute 'strip'

I just tried out fbcap on my messages.htm file.  It begins to process the file, but then it dies as follows:
$ fbcap messages.htm
Discovered chat thread with [XXX,YYY,ZZZ]...Traceback (most recent call last):
  File "/usr/local/bin/fbcap", line 9, in <module>
    load_entry_point('fbchat-archive-parser==0.4', 'console_scripts', 'fbcap')()
  File "build/bdist.macosx-10.10-intel/egg/fbchat_archive_parser/main.py", line 66, in main
  File "/Library/Python/2.7/site-packages/clip.py", line 652, in run
    self.invoke(self.parse(tokens))
  File "/Library/Python/2.7/site-packages/clip.py", line 634, in invoke
    self._main.invoke(parsed)
  File "/Library/Python/2.7/site-packages/clip.py", line 519, in invoke
    self._callback(**{k: v for k, v in iteritems(parsed) if k not in self._subcommands})
  File "build/bdist.macosx-10.10-intel/egg/fbchat_archive_parser/main.py", line 27, in fbcap
  File "build/bdist.macosx-10.10-intel/egg/fbchat_archive_parser/parser.py", line 98, in __init__
  File "build/bdist.macosx-10.10-intel/egg/fbchat_archive_parser/parser.py", line 108, in __parse_content
  File "build/bdist.macosx-10.10-intel/egg/fbchat_archive_parser/parser.py", line 174, in __process_element
AttributeError: 'NoneType' object has no attribute 'strip'

I tried python 2.7 and 3.5.1 just for fun, same results.

Interesting, that would imply that in your messages.htm file, you have a thread that lacks information regarding who the participants are. I'm not sure what that means, but seeing as it's rare, I've put in a fix to skip those threads and assume they're corrupted.
I just updated the version of the tool on PyPI (version 0.4.post1). Let me know if that helps!

That fixed it, thanks.


Updated the darwin area of the Makefile to more accurate variable nam…

…es: changed OS_VERSION to OSX_SDK_VERSION.

Most of these changes are based upon Haris Andrianakis' comments to my last PR.  Thanks!

Hi @tl0gic - will you take this - I've already too much mess to the macos :)

Hey @robertswiecki, sure thing!
@aaronc100 thanks for doing this! I think overall it looks good, I left you one small comment. Let me know what you think.


Can't get it to work on macos

payload-dumper-go /path/to/payload.bin
zsh: exec format error: payload-dumper-go
getting this error I have set it as system path aswell in zshrc file

You downloaded payload-dumper-go for the wrong CPU architecture?

no arm64 only I am on m1 mac

file $(which payload-dumper-go) what does that say?

payload-dumper-go: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, BuildID[sha1]=8b9902f966324bf509a516aa5bc389823c5a4e15, for GNU/Linux 3.7.0, stripped
not:               cannot open not' (No such file or directory) found:             cannot open found' (No such file or directory)

So you downloaded payload-dumper-go for Linux instead of Darwin. Not surprising it doesn't work.

ohh macos is darwin i though its linux


Category subtotal coloring not matching with actual category header coloring after tool reset

When loading up the GB, the category subtotal color icon matches the category header row. However, after resetting the GB tool, you end up with discrepancies like this:

Confirmed!


bump go to 1.16

IMPORTANT: Please do not create a Pull Request without creating an issue first.
Problem:
Bump Harvester go dependency to 1.16 to it consistent with Rancher 2.6
Solution:
Bump Harvester Go dependency to 1.16 and controller-gen to 0.5 respectively.
Related Issue:
https://github.com/harvester/harvester/issues/916
Test plan:
N/A

@gitlawr suggests fixing the kubevirt API doc dependency with a blank import:
diff --git a/pkg/genswagger/main.go b/pkg/genswagger/main.go
index 5eb2518f..02f4c5bf 100644
--- a/pkg/genswagger/main.go
+++ b/pkg/genswagger/main.go
@@ -11,6 +11,7 @@ import (
        "github.com/go-openapi/spec"
        "k8s.io/kube-openapi/pkg/builder"
        "k8s.io/kube-openapi/pkg/common"
+       _ "kubevirt.io/client-go/apis/snapshot/v1alpha1"

        "github.com/harvester/harvester/pkg/apis/harvesterhci.io/v1beta1"
        "github.com/harvester/harvester/pkg/genswagger/rest"


:seedling: Ignore the all broker is down error for producer client

Summary
Related issue(s)
Fixes # https://github.com/open-cluster-management-io/sdk-go/pull/44

/cc @clyang82 @ldpliu