jucipp icon indicating copy to clipboard operation
jucipp copied to clipboard

Jucipp gets stuck when changing CMakeList

Open leonid-rousniak opened this issue 9 years ago • 15 comments

Hello,

If I try to modify the build system (CMakeList.txt for example), jucipp gets stuck forever with "Creating/updating default build" window. stuck When it happens, I have to kill the program. Close button do not work anymore.

I am using Ubuntu 16.04.1 LTS

leonid-rousniak avatar Nov 02 '16 08:11 leonid-rousniak

Does it look like cmake is running and exiting normally, or does cmake never return in your case? You could try see what happens when running cmake manually (I guess it is possible to create an infinite loop in a cmake script). If cmake is exiting as it should, the dialog should be closed.

eidheim avatar Nov 02 '16 08:11 eidheim

I am not sure I understood what you meant. A reproducible example:

-In an empty folder, create a new C++ project. -Open CMakeList.txt in the tree. -replace the flag "-std=c++1y" by "-std=c++14" -save

When I save it gets stuck with the same window as in the screenshot. I don't see anything else happening. The only way to modify the CMakeList.txt "cleanly" is to close jucipp, modify the file with vim and relaunch jucipp. Then the update is good.

leonid-rousniak avatar Nov 02 '16 09:11 leonid-rousniak

I'm unable to reproduce this on my Ubuntu 16.04, what is the output of cmake --version?

Also, try the following:

  1. Modify CMakeLists.txt with vim in your new C++ project and exit vim
  2. from the new C++ project folder, in a terminal type:
cd build && cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON ..

Does the above command result in an infinite loop?

eidheim avatar Nov 02 '16 09:11 eidheim

I am using cmake 3.5.1. I just tried what you asked me and it worked fine:

-- Configuring done
-- Generating done
-- Build files have been written to: /home/rousniak/test/testjuci/build

leonid-rousniak avatar Nov 02 '16 09:11 leonid-rousniak

The following diff removes the message dialog on create/update builds:

diff --git a/src/cmake.cc b/src/cmake.cc
index 1259782..e938389 100644
--- a/src/cmake.cc
+++ b/src/cmake.cc
@@ -54,10 +54,10 @@ bool CMake::update_default_build(const boost::filesystem::path &default_build_pa
     return true;

   auto compile_commands_path=default_build_path/"compile_commands.json";
-  Dialog::Message message("Creating/updating default build");
+  // Dialog::Message message("Creating/updating default build");
   auto exit_status=Terminal::get().process(Config::get().project.cmake_command+" "+
                                            filesystem::escape_argument(project_path)+" -DCMAKE_EXPORT_COMPILE_COMMANDS=ON", default_build_path);
-  message.hide();
+  // message.hide();
   if(exit_status==EXIT_SUCCESS) {
 #ifdef _WIN32 //Temporary fix to MSYS2's libclang
     auto compile_commands_file=filesystem::read(compile_commands_path);
@@ -101,11 +101,11 @@ bool CMake::update_debug_build(const boost::filesystem::path &debug_build_path,
   if(!force && boost::filesystem::exists(debug_build_path/"CMakeCache.txt"))
     return true;

-  auto message=std::make_unique<Dialog::Message>("Creating/updating debug build");
+  // auto message=std::make_unique<Dialog::Message>("Creating/updating debug build");
   auto exit_status=Terminal::get().process(Config::get().project.cmake_command+" "+
                                            filesystem::escape_argument(project_path)+" -DCMAKE_BUILD_TYPE=Debug", debug_build_path);
-  if(message)
-    message->hide();
+  // if(message)
+  //   message->hide();
   if(exit_status==EXIT_SUCCESS)
     return true;
   return false;

Would you mind applying it to your jucipp sources and see if this diff resolves your problem?

eidheim avatar Nov 02 '16 10:11 eidheim

Works perfectly! Thanks.

leonid-rousniak avatar Nov 02 '16 10:11 leonid-rousniak

Thank you! I actually suspect that the freeze happens here: https://github.com/cppit/jucipp/blob/master/src/dialogs.cc#L27. I'll test removing it and see if the dialog still appears correctly on a native linux machine soon.

eidheim avatar Nov 02 '16 10:11 eidheim

@leonid-rousniak I have trouble finding a good solution for this issue and still be able to show the update dialogs. Could you give me some more information of your system, and I could then maybe be able to reproduce the issue. Are you running a standard installation of Ubuntu 16, or are you using a different desktop environment like KDE, and/or a different display manager like for instance Wayland?

eidheim avatar Nov 02 '16 13:11 eidheim

I am using a standard Ubuntu 16 in a virtual machine. It has the particularity of being offline, so I had to compile most dependencies from source. It might be that I messed up somewhere.

Since it looks like I am the only one with the problem, I wouldn't worry too much about it.

leonid-rousniak avatar Nov 02 '16 14:11 leonid-rousniak

Well, we do not want freezes in juCi++:) What kind of virtual machine are you using? VirtualBox or VMWare maybe?

eidheim avatar Nov 02 '16 15:11 eidheim

@eidheim Can we observe the file descriptors of the process?

zalox avatar Nov 02 '16 15:11 zalox

Ah, I forgot to add that I actually use xfce for the desktop environment . But I downloaded the "xubuntu" iso, didn't set it up myself.

As for the vm, I use VMware Workstation 12 Player.

leonid-rousniak avatar Nov 02 '16 15:11 leonid-rousniak

@zalox You find the file descriptors here: https://github.com/eidheim/tiny-process-library/blob/master/process.hpp#L78. But this was not the issue. The issue is creating the "update/create build"-dialog and waiting for it to be shown while cmake is running. I'm going to see if I can reproduce the problem on Xubuntu Tomorrow. I have created a "fix" here I think: https://github.com/eidheim/jucipp/commit/a57e67afbcc065f57bf893b28436928a79c58a4d, but not 100% sure that this is the best way to solve it yet.

eidheim avatar Nov 02 '16 18:11 eidheim

@leonid-rousniak I have tried latest Xubuntu on both Virtual Box and VMWare Workstation Player, but still unable to reproduce this issue. The problem might somehow lie in the package sources you have compiled manually I'm thinking now.

eidheim avatar Nov 03 '16 15:11 eidheim

Yes, probably. Anyway thanks a lot for your help!

leonid-rousniak avatar Nov 04 '16 09:11 leonid-rousniak