RAK_4631 PRIVATE_HW definition is fundamentally broken (accoring to closed issue)

[jbuck2005]

          > RAK_4631 especially is tied to a lot of things inside the source code that makes the module work as expected. You can add another define to act upon in macro guards but please never replace it. If you want to signal a'private hw' you can add your macro to the architecture.h for nrf52 platform.

Why would this have worked previously though? (changing from RAK_4631 to PRIVATE_HW in the platformio.ini)

Further, what you are suggestion actually is contrary to what is posted as part of the development documentaion.
https://meshtastic.org/docs/development/firmware/build/

Originally posted by @jbuck2005 in #5107 (comment)

[jbuck2005]

I maintain that this is a bug and what was proposed in closing the original issue is NOT appropriate and directly conflicts with the documentation.

[caveman99]

Further, what you are suggestion actually is contrary to what is posted as part of the development documentaion. https://meshtastic.org/docs/development/firmware/build/

I know what is written there because i wrote most of it. What's also true is that if you start from the 4631 template (which is NOT used in the docs) you are bound for trouble, and i just alerted you to the fact. pick any other nRF52 target and you'll be fine. if you use the 4630/1 in your design look how monteops_hw1 did it.

Furthermore maintain what you want, proceed as you deem right and if it breaks you own both parts. But in future please consider how you approach these things, because the answer you get might be in the same aggressive tone.

Nothing is 'Fundamentally broken'. I am not gonna refactor half of the sourcecode because someone has a hissy fit over a macro definition.

[jbuck2005]

Wow - take a look inside, dude. I think you are perhaps a bit stressed. The phenomenon you are exhibiting with your response is known as projection.

In fact, the code base is fundamentally broken since the RAK4631 was coded in such a divergent way. I have no doubt that it was necessary to make the decisions which led to where to code is currently - that is not being debated. There is no need to become so defensive about the state of the code; own it. I certainly could not have done what you and others have achieved.

Perhaps I can help you to update the documentation to alert future tinkerers to this quirk of developing for the RAK4631?

[fifieldt]

Take it easy folks :)

I think in general we do want to keep as much of the variant-specific stuff in the variant and out of the main code as practical. Personally I've done a bit of cleanup on main.cpp, for example. However, sometimes it's just not possible.

Working on a major update to variant documentation at meshtastic/meshtastic#1363 (scratch notes here: https://docs.google.com/document/d/1EIkAqGxw3_g9U7NxUNePDnH9X-LWJeZILUGYFmAvxZI/edit?tab=t.0 ). I think that would be quite useful - a place where people making their own variant can start. It's quite time consuming ... I'd appreciate help :)

[caveman99]

In fact, the code base is fundamentally broken since the RAK4631 was coded in such a divergent way. I have no doubt that it was necessary to make the decisions which led to where to code is currently - that is not being debated. There is no need to become so defensive about the state of the code; own it. I certainly could not have done what you and others have achieved.

I gave you two hints how you can circumvent the issue. You circle back and try to create a problem where there is no problem while not being interested in a solution (or two solutions for that matter). Plus you chose to get personal over this. (i am not stressed, thanks for asking). I have no time for atificial drama, this discussion ends here.