little problems

[Rafał Pietrak]

I sincerely apologize for abusing this list, but since gitlab decline my
registration I pretty much have no other option to notify you.

1. I've recently pull kicad sources and they want compile on my Debian
stable (12.9). The following patch solves the problem, but I'm pretty
sure it's not the correct action to take (earlier there was a section
acting on KICAD_USE_CMAKE_FINDPROTOBUF depending on target being linux
or not ... which might be more appropriate, but I haven't tested it):
----------------
diff --git a/CMakeLists.txt b/CMakeLists.txt
index fb2130e910..05d29fbb73 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -167,7 +167,7 @@ cmake_dependent_option(
KICAD_APPLE_MAKE_RELOCATEABLE_BUNDLE

# Old versions of CMake and/or protobuf can require the
FindProtobuf.cmake,
# but modern platforms require this to be off
-option( KICAD_USE_CMAKE_FINDPROTOBUF "Use FindProtobuf provided by
CMake" OFF )
+option( KICAD_USE_CMAKE_FINDPROTOBUF "Use FindProtobuf provided by
CMake" ON )
mark_as_advanced( KICAD_USE_CMAKE_FINDPROTOBUF )

####################################
--------------------------------
With this patch compiling on Debian 12.9 is correct.

2. The ReplicateLayout I used some time ago with KiCAD version 6.0 (as
provided by Debian stable package) worked perfectly. It made KiCAD "a
better place". Since then I've tried the KiCAD locally compiled as
pulled from gitlab, but the ReplicateLayout didn't work with any of them
(v7, v8, now v9). I've asked the author on github for a fix, but the
explanation was, that it's the KiCAD bug. That's why I just waited for
"the fix". But currently we have v9rc2 and there is no "fix" to make
that plugin work. Can somebody shred some light on what's happening
here? (The attachment is an error thrown by the plugin, when forced to
run on v9rc2). Is this really a "kicad fix" or just ReplicationLayout
author "preference" to some other specifics of the implementaion? What
and how one should do in the plugin ... instead of the iteration so
upsetting the ReplicateLayout plugin? Like what instead of
"board.GetEnabledLayers().Users()"?

Best regards to you all

-R

[Ladislav Laska]

Hi Rafal,

I don't think this is a change you're supposed to do in CMakeLists.
Since it's an option, I think it should be possible to invoke cmake
with:

-DKICAD_USE_CMAKE_FINDPROTOBUF=ON

Does that not work for you?

I can't speak for the second issue. However, I'd like to note that kicad
6 was released in 2021, so you made a good choice compiling a new
version (I'd also suggest moving to a more flexible distro for desktop
application, but that's out of scope).

Do you have a reference ticket that discusses the bug? To me, it seems
more like the plugin wasn't updated to the new versions of KiCAD, and I
know there were some significant scripting changes.

Cheers,
Ladislav

> --
> You received this message because you are subscribed to the Google Groups "KiCad Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to devlist+u...@kicad.org.
> To view this discussion visit https://groups.google.com/a/kicad.org/d/msgid/devlist/35361a3d-60af-4f47-a4f9-6b2e46d9acfc%40electric-sheep.eu.



--
S pozdravem Ladislav "Krakonoš" Láska http://www.krakonos.org/

[Rafał Pietrak]

Hi Ladislav

On 6.02.2025 10:42, Ladislav Laska wrote:
> Hi Rafal,
>
> I don't think this is a change you're supposed to do in CMakeLists.
> Since it's an option, I think it should be possible to invoke cmake
> with:
>
> -DKICAD_USE_CMAKE_FINDPROTOBUF=ON
>
> Does that not work for you?

It does work, thank you.

Still, I'd expect such errors shouldn't pop up within "current stable"
distribution (whatever the distribution). So, I've let you know about
the issue.

[--------------]

> Do you have a reference ticket that discusses the bug? To me, it seems
> more like the plugin wasn't updated to the new versions of KiCAD, and I
> know there were some significant scripting changes.

https://github.com/MitjaNemec/ReplicateLayout/issues/70

Additionally, I've received the following info by mail:
----------------------------
The plugin might or might not work with 8.99.

Is there anything I could do to help bring up this plugin to v8.99
compatibility?
you might not need to do anything.

As I don't support the compatibility with 8.99 the plugin is marked so
that PCM will not install it. So your only issue is how to install the
plugin, so that you can check if it works. The easiest way would be to
copy the plugin contents into the folder where KiCad can find it (on MSW
that would be in subfolder within "%APPDATA%\kicad\8.99\scripting\plugins")

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.
-------------------------------------

The plugin is still marked as "incompatible". I've "forced" it's
download and manually "unmarked" that flag (to get the error in
question). So, some issues remain, and I really don't know where the
problem is: KiCAD or the plugin.

-R

[Seth Hillbrand]

On Thu, Feb 6, 2025 at 6:09 AM Rafał Pietrak <sol...@electric-sheep.eu> wrote:

Hi Ladislav

On 6.02.2025 10:42, Ladislav Laska wrote:
> Hi Rafal,
>
> I don't think this is a change you're supposed to do in CMakeLists.
> Since it's an option, I think it should be possible to invoke cmake
> with:
>
>    -DKICAD_USE_CMAKE_FINDPROTOBUF=ON
>
> Does that not work for you?

It does work, thank you.

Still, I'd expect such errors shouldn't pop up within "current stable"
distribution (whatever the distribution). So, I've let you know about
the issue.

Current stable refers to distributions.  If you are compiling on your own, you should expect to need some configuration based on your local development environment.  We have extensive documentation on the build process at https://dev-docs.kicad.org/en/build/linux/index.html .  Here is the first part of that documentation:

Regarding the plugin, you might currently find this functionality built into KiCad (https://docs.kicad.org/master/en/pcbnew/pcbnew.html#multichannel)

Seth

Seth Hillbrand

Lead Developer

+1-530-302-5483‬

Long Beach, CA

www.kipro-pcb.com    in...@kipro-pcb.com

[Rafał Pietrak]

Hi!

On 6.02.2025 18:27, 'Seth Hillbrand' via KiCad Developers wrote:
[-------------]

> Current stable refers to distributions.  If you are compiling on your
> own, you should expect to need some configuration based on your local
> development environment.  We have extensive documentation on the build
> process at https://dev-docs.kicad.org/en/build/linux/index.html
> <https://dev-docs.kicad.org/en/build/linux/index.html> .  Here is the
> first part of that documentation:

> image.png

I see. So you are not interested (i.e. probably knew it already), that
something that worked fine by default just a month ago, currently
requires digging into documentation.

OK.

>
> Regarding the plugin, you might currently find this functionality built
> into KiCad (https://docs.kicad.org/master/en/pcbnew/

> pcbnew.html#multichannel <https://docs.kicad.org/master/en/pcbnew/
> pcbnew.html#multichannel>)

EXCELLENT! Thenx!!!

-R

[Ladislav Laska]

Hi Rafal,

I don't know the details of the protobuf issue. However, I think the
comment above says it:

# Old versions of CMake and/or protobuf can require the FindProtobuf.cmake,
# but modern platforms require this to be off

Setting this to the ON value would likely break some up to date
platform. Other people would have to dig into documentation. In general,
recent software should be compatible with recent distributions. Debian
12 relesed on 2023 with kicad 6.0 that released 2021 and cmake 3.25
released in 2021. I think this qualifies as older version and you should
be expecting to run into issues. I'm surprised this is the only problem.

I wanted to suggest upgrading your distro to fix it, but while writing
this paragraph I noticed there seem to be newer cmake & kicad in
backports repository. Perhaps this would fix your problems and allow you
to build even newer versions? Repo bookworm-backports has cmake 3.31,
that should not require this switch. But I haven't tested.

Regards,
Ladislav

> --
> You received this message because you are subscribed to the Google Groups "KiCad Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to devlist+u...@kicad.org.

> To view this discussion visit https://groups.google.com/a/kicad.org/d/msgid/devlist/6ebf026e-1ec0-44fd-ae00-435d67c93d59%40electric-sheep.eu.

[Rafał Pietrak]

Hi Ladislav,

First of all - I don't think this case is worth any further discussion.
I fully agree with you, that debian stable has particularly ancient
version of KiCAD and cmake.

Having said that....

On 7.02.2025 09:22, Ladislav Laska wrote:
> Hi Rafal,
>
> I don't know the details of the protobuf issue. However, I think the
> comment above says it:
>
> # Old versions of CMake and/or protobuf can require the FindProtobuf.cmake,
> # but modern platforms require this to be off
>
> Setting this to the ON value would likely break some up to date
> platform. Other people would have to dig into documentation. In general,
> recent software should be compatible with recent distributions. Debian
> 12 relesed on 2023 with kicad 6.0 that released 2021 and cmake 3.25
> released in 2021. I think this qualifies as older version and you should
> be expecting to run into issues. I'm surprised this is the only problem.

Exactly.

> I wanted to suggest upgrading your distro to fix it, but while writing
> this paragraph I noticed there seem to be newer cmake & kicad in
> backports repository. Perhaps this would fix your problems and allow you
> to build even newer versions? Repo bookworm-backports has cmake 3.31,
> that should not require this switch. But I haven't tested.

But here I disagree. As I admit that current software versions (like
KiCAD v9) should take advantage of new tools as they become available.
At the same time it's worth keeping compatibility with (at least) one
earlier "generation" of the "environments". And debian stable is
something playing a role of such "just previous generation" quite well.

Then again. IMHO, using cmake (as opposed to automake/make) main purpose
is that one could easier take into account diversity of environments -
like keeping some backward compatibility... I thought (... but I
personally never needed that. Plain make worked just fine for me, so I'm
not particularly proficient in tweaking cmake setups).

But OK. I'm not complaining, and I'm not trying to push anything here.
Pls have my apologize for triggering this unintended noise on the list.

best regards to you all,

-R

[Ladislav Laska]

Hi Rafal,

thanks for the feedback. I think we're on the same page, just have
slightly different thresholds on where the cut is. I think that's OK.
Let's get back to solving actual issues then :-)

Regards,
Ladislav

> --
> You received this message because you are subscribed to the Google Groups "KiCad Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to devlist+u...@kicad.org.

> To view this discussion visit https://groups.google.com/a/kicad.org/d/msgid/devlist/e6b9ad31-ec6e-4587-a4e9-195f70fa003f%40electric-sheep.eu.