Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TP local builds #1032

Open
rgleason opened this issue Oct 17, 2023 · 3 comments
Open

TP local builds #1032

rgleason opened this issue Oct 17, 2023 · 3 comments

Comments

@rgleason
Copy link
Contributor

@transmitterdan
@seandepagnier

How to build locally in Linux,RPI and Android?? Does not work on RPI #38
We would like to provide guidance on how to do this.
Any suggestions?

Sean would like a simple direct way to build and test plugins on linux, RPI and Android.
He does not like the many steps required to "import plugin" tarballs and would like to simply install
to binary to the right location with a script. Is this possible?

@jongough
Copy link
Contributor

Copying the dll/so/whatever to the requisite location is how I do testing without going through the packaging. But I am running debugging to fix stuff up so I am building OCPN as well as the plugins I am working on. I use an IDE to do this, I am not really sure why command line building is such a problem. If you want command line then use 'circleci local' if you want cloud build use the ones in cloudsmith, if you want debug code then use an IDE, if you really need command line then create the environment variables needed (there are only a couple for most builds) then execute the script that circleci does. I do this occasionally when debugging the circleci process.

Not really sure how many other ways to build need to be done. The testplugin/FE2 build process is to help create plugins easily and build and deploy them. It is not intended to be the ultimate tool for all development on all platforms as everyone works differently. But the build processes do work and they concentrate all plugin specific changes in one file, the CMakeList.txt file (for out of the ordinary builds it is flexible enough to allow 'extras' to be added).

@seandepagnier
Copy link

seandepagnier commented Dec 29, 2023

It used to be I could type "sudo make install" in the build folder of a plugin, and start opencpn and test it. In fact I still can if I apply:

`
diff --git a/src/plugin_loader.cpp b/src/plugin_loader.cpp
index 97a8de4a4..10259c44e 100644
--- a/src/plugin_loader.cpp
+++ b/src/plugin_loader.cpp
@@ -316,7 +316,7 @@ bool PluginLoader::LoadPluginCandidate(wxString file_name, bool load_enabled) {
base_plugin_path += wxFileName::GetPathSeparator();

if (base_plugin_path.IsSameAs(plugin_file_path)){

  • if (!IsSystemPlugin(file_name.ToStdString())){
  • if (!IsSystemPlugin(file_name.ToStdString())&&0){
    DEBUG_LOG << "Skipping plugin " << file_name << " in " << g_BasePlatform->GetPluginDir();
    return false;
    }
    `

What is the process now instead? I prefer a simple single command. Is there some reason opencpn really needs to ignore plugins in /usr/local considering that only developers or people who build from source and use make install will have this?

@transmitterdan
Copy link

There is another thread discussing this. I think we will soon have it back to how it was.

OpenCPN/OpenCPN#3553

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants