search

ra3xdh / qucs_s

Qucs-S is a circuit simulation program with Qt-based GUI
https://ra3xdh.github.io/
GNU General Public License v2.0
839 stars 108 forks source link

Qt5 migration checklist #72

Closed ra3xdh closed 2 years ago

ra3xdh commented 2 years ago

The following things need to be done to complete the Qt5 migration. The Qt5 port is located here: https://github.com/ra3xdh/qucs_s/tree/qt5

kwmartin commented 2 years ago

sudo apt-get install libqt5svg5-dev qtscript5-dev seems to be required,

ra3xdh commented 2 years ago

Yes, the main application requires QtSvg and QtScript. It will be needed to update the build instructions later.

ra3xdh commented 2 years ago

I have fixed some issues in the main application. Now everything seems to work. I have tested save/load, circuit editing, subcirctuits, library components from user libraries, and simulation with Ngspice. The next step is to port utilities to Qt5.

ra3xdh commented 2 years ago

I have ported utilities to Qt5. Everything seems to be working.

ra3xdh commented 2 years ago

Main CMakeList.txt is fixed. Now the Qucs-S could be correctly installed. Drag'n'Drop form library window doesn't work. Drag'n'Drop form library side dock is not affected.

kwmartin commented 2 years ago

In CMakeList.txt, I see: FIND_PACKAGE( Qt5 COMPONENTS Core Gui Widgets LinguistTools Script REQUIRED ) My OS (Ubuntu 20.04) has an apt qt4-linguist-tools but no qt5-linguist-tools. Do you know which apt I should install in order to use LinguistTools? Thank you.

ra3xdh commented 2 years ago

The lrelease and lupdate utilities from linguist are the part of the qttools5-dev-tools package on my Kubunut18.04 system.

dpkg -S /usr/lib/qt5/bin/lrelease
qttools5-dev-tools: /usr/lib/qt5/bin/lrelease
kwmartin commented 2 years ago

Thanks Vadim, the qttools5-dev-tool package helped; but for some reason the QT_CONFIG macro is not coming in.

[ 71%] Built target paintings [ 76%] Built target extsimkernels [ 76%] Building CXX object qucs/CMakeFiles/qucs-s.dir/main.cpp.o In file included from /usr/include/x86_64-linux-gnu/qt5/QtSvg/QtSvgDepends:5, from /usr/include/x86_64-linux-gnu/qt5/QtSvg/QtSvg:3, from /home/martin/IC_Design/Qucs_s_Qt5/qucs_s/qucs/main.cpp:39: /usr/include/x86_64-linux-gnu/qt5/QtWidgets/QtWidgets:5:14: error: missing binary operator before token "(" 5 | #if QT_CONFIG(abstractbutton) | ^ /usr/include/x86_64-linux-gnu/qt5/QtWidgets/QtWidgets:8:14: error: missing binary operator before token "(" 8 | #if QT_CONFIG(itemviews) | ^ And so on; some other macros are also not coming in. My guess is we need to direct cmake to add a cxx flag having something like:

-I/usr/include/x86_64-linux-gnu/qt5/QtCore/ but this should be somewhat automatic with Qt. It might be that when I installed Qt4, it messed up Qt5?

On my machine, QT_CONFIG is defined in:

/usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h

/ The QT_CONFIG macro implements a safe compile time check for features of Qt. Features can be in three states: 0 or undefined: This will lead to a compile error when testing for it -1: The feature is not available 1: The feature is available /

define QT_CONFIG(feature) (1/QTFEATURE##feature == 1)

define QT_REQUIRE_CONFIG(feature) Q_STATIC_ASSERT_X(QTFEATURE##feature == 1, "Required feature " #feature " for file " FILE " not available.")

I'll keep plugging away, but am stumped right now!

ra3xdh commented 2 years ago

Hello Kenneth,

I cannot reproduce the reported build issue on my Kubuntu 18.04 machine. It seems that your Qt5 installation is damaged. I am using the following build sequence at the top of the source tree:

git clone https://github.com/ra3xdh/qucs_s
git checkout -b qt5 origin/qt5
cd qucs_s
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=install_prefix -DCMAKE_BUILD_TYPE=Release ..
make

Alternatively you may open the CMakeLists.txt with QtCreator. This way may be more convenient.

Where and how is the Qt4 installed on your machine? Also try to run make VERBOSE=1. You will see the detailed g++ call and actual compiler arguments. The include flags of the normally compiler should be set automatically. Are you using in-source build or the build directory? The in-source build is not recommended and my cause such strange issues. Did you build the Qt4 version in the same source tree? Also try to clear CMake caches.

I will try to install fresh Ubuntu 20.04 into the virtual machine and reproduce the build sequence on the clean system.

kwmartin commented 2 years ago

Hi Vadim, git fetch origin git switch qt5

With your CMakeLists.txt in a build directory (for me bld1):

cmake .. -DCMAKE_INSTALL_PREFIX=/usr/local -- Configuring Qucs: VERSION 0.0.22 -- qucs-suite /usr/local /home/martin/IC_Design/Qucs_s_Qt5/qucs_s/bld1 CMake Error at /usr/lib/x86_64-linux-gnu/cmake/Qt5/Qt5Config.cmake:28 (find_package): Could not find a package configuration file provided by "Qt5LinguistTools" with any of the following names:

Qt5LinguistToolsConfig.cmake
qt5linguisttools-config.cmake

Add the installation prefix of "Qt5LinguistTools" to CMAKE_PREFIX_PATH or set "Qt5LinguistTools_DIR" to a directory containing one of the above files. If "Qt5LinguistTools" provides a separate development package or SDK, be sure it has been installed. Call Stack (most recent call first): CMakeLists.txt:26 (FIND_PACKAGE)

-- Configuring incomplete, errors occurred! See also "/home/martin/IC_Design/Qucs_s_Qt5/qucs_s/bld1/CMakeFiles/CMakeOutput.log". See also "/home/martin/IC_Design/Qucs_s_Qt5/qucs_s/bld1/CMakeFiles/CMakeError.log".

I haven't used QtCreator for a number of years; I remember at that time I didn't like the lack of control. Going back would put me on hold for a long time. If necessary, I will, but this is a last resort. Before this, I would stop everything and try and debug cmake with a build directory.

Re qt4: /usr/include/qt4/ Re qt5: /usr/include/x86_64-linux-gnu/qt5/

c /usr/lib/x86_64-linux-gnu/qt-default/qtchooser/default.conf /usr/lib/qt5/bin /usr/lib/x86_64-linux-gnu

qtchooser -print-env QT_SELECT="qt5" QTTOOLDIR="/usr/lib/qt5/bin" QTLIBDIR="/usr/lib/x86_64-linux-gnu"

moving the cmake cache file away didn't help cmake .. -DCMAKE_INSTALL_PREFIX=/usr/local -DCMAKE_CXX_FLAGS=-I/usr/include/x86_64-linux-gnu/qt5/ also didn't help. I had cmake working previously (after a lot of hours), but not make, and now I can't get back to getting cmake working; I guess I should have recorded what I was doing better before pulling the most recent build, but it is what it is. I always always spend way more time trying to get clean build going where I can run gdb then I ever do on actual development.

Maybe we should give up on cmake and try and get spack working? Or try a gnumake approach? using bootstrap, config, make in the top directory, etc?

Right now, I'm blindly doing trial and error with no success

ra3xdh commented 2 years ago

I have installed a clean Ubuntu20.04 system with Qt5.12 on a VirtualBox machine. I also cannot reproduce this issue. Everything has been compiled without errors and qucs-s application runs normally. I have the following packages installed:

sudo apt-get install build-essential git cmake qtbase5-dev qttools5-dev qtscript5-dev libqt5svg5-dev

Maybe we should give up on cmake and try and get spack working?

The changing of the build system is not considered. CMake was always used with Qucs-S. Regarding this issue, there is something wrong with your Qt5 or CMake configuration, but I cannot figure out what exactly. Probably Qt4 replaced some CMake scripts after the installation. What qmake --version prints? What for lrelease -version and lupdate -version? Could you compile only executable in the qucs subdirectory without translations?

kwmartin commented 2 years ago

The sudo apt-get install build-essential git cmake qtbase5-dev qttools5-dev qtscript5-dev libqt5svg5-dev may have solved it. To be more specific, it's looking there may have been a problem with "cmake" dependencies that may have been corrupted. cmake-data libjsoncpp1 librhash0 I need a few more hours, but as I get more info, I will post here (hopefully some-time tomorrow). Thanks Vadim, you've been exceedingly helpful.

kwmartin commented 2 years ago

Also, for info:

qmake --version QMake version 3.1 Using Qt version 5.12.8 in /usr/lib/x86_64-linux-gnu lupdate -version lupdate version 5.12.8

tvrusso commented 2 years ago

Guys: Just wanted to let you know that I've been following this issue and just today checked out the qt5 branch and tested it on FreeBSD very briefly. I was able to load some old schematics I had from before my system dropped qt4 and they loaded up just fine, and I was able to run Xyce through Qucs-s just as I used to be able to do. I have not tried out very much more than that.

The only thing I had to do was install the "qt5-script" package, which was not otherwise installed by the big qt5 meta-package on this system. I'd already had cmake and the rest of qt5 already installed for other reasons.

tvrusso commented 2 years ago

On the other hand, there do seem to be some font issues as things don't really look quite right yet.

In the attached image, note the screwy appearance of vertical text.

image

ra3xdh commented 2 years ago

Hello Tom, that is a good news that everything builds on FreeBSD. Unfortunately I cannot test this OS by myself. Another good news that Xyce support is not broken. I had concerns that something may become outdated, because the last Xyce version tested with Qucs-S was 6.8. I will try to compile Xyce on my Kubuntu18.04 and test it more in details.

do seem to be some font issues as things don't really look quite right yet

I cannot reproduce these issues on Linux. Besides my host system I have tested Ubuntu20.04 and Manjaro with Qt5.12 and 5.15. Everything looks good for such platform. Maybe QFontMetrics gives incorrect results on FreeBSD. There may be something weird with the font settings if it was inherited from the old Qucs installation.

image

ra3xdh commented 2 years ago

I have fixed the Qt5.15 build with the latest commits on qt5 branch. The application could be run on Manjaro, but it remains a lot of warnings regarding deprecated Qt routines. I hope to prepare a release candidate and AppImage in the next week.

tvrusso commented 2 years ago

Hmmm. Your settings dialog looks exactly like mine (same font name and specification, same large size). I even tried telling qucs-s to reset that dialog to defaults and restarted it with no change in behavior.

What's really strange is that the vertical text is running from bottom to top as expected, but the letters themselves are not rotated at all, so it looks really strange.

image

Never saw this in the qt4 version, but it's been a very long time since I have used that (FreeBSD dropped qt4 from its package system quite a long time ago).

I have just built qucs-s with qt5 on my Ubuntu laptop and I do NOT see the same thing.

tvrusso commented 2 years ago

There is plenty of room for Xyce support to be broken, as there has been a lot of development regarding things like sensitivity output. But what might break is just something specific to one or two of your Xyce examples. Since all you're doing is generating netlists and running the binary, the good news is that nothing fundamental is broken.

ra3xdh commented 2 years ago

I have installed Xyce on my machine. All my test examples including .HB analysis work normally. Only Fourier .FOUR analysis is broken. The old Qt4 Qucs-S is affected too. Probably something was changed in the output format.

tvrusso commented 2 years ago

I have installed Xyce on my machine. All my test examples including .HB analysis work normally. Only Fourier .FOUR analysis is broken. The old Qt4 Qucs-S is affected too. Probably something was changed in the output format.

Yeah, Xyce 7.5 and the development version of Xyce in git has some changes to the formatting of sensitivity output that might break some examples, but 7.5 won't be out for a few months. Not sure what changed in .FOUR output.

ra3xdh commented 2 years ago

@tvrusso Could you test the branch https://github.com/ra3xdh/qucs_s/tree/qt5_default_font ? It sets the application font to system font instead of "Helvetica" and may resolve your issue on FreeBSD. It seems that "Helvetica" may be invalid on some platforms and can lead to weird result. You need to delete the config file $HOME/.config/qucs/qucs_s.conf before testing this feature to reset the font settings.

tvrusso commented 2 years ago

Helvetica is installed on this system. I will, however, try the qt5_default_font branch.

tvrusso commented 2 years ago

But yes, if I build the qt_default_font branch then the vertical labels are all correct.

image

image

ra3xdh commented 2 years ago

It seems that weird issue has gone. I also had report about similar problem from Arch Linux users. I will merge this commit in qt5 branch then. Could you look what is the font name is in the application settings now?

tvrusso commented 2 years ago

The font name is now "Sans Serif, 12, -1,5,50,0,0,0,0,0"

ra3xdh commented 2 years ago

The application font setting fix is merged in qt5 branch now. Despite the remaining issues I am intending to switch master branch to Qt5 and make a release candidate in the next week. I will also prepare AppImage for Qt5 version.

kwmartin commented 2 years ago

I now have Xyce simulating with Vadim's second recent update; I will update again soon and re-try. I haven't gotten around to figure out how to graph the results yet; my guess is I need to bring a "Graph" component onto the schemtic? I'll figure it out. I am also in the process of trying to get an ADMS generic 22nm EKV model from Christian Enz of EPFL. I expect Christian will send the model; I will work on getting it running first in Xyce at command line. No idea how difficult it might be. Vadim, your success is really moving things forward. I'm on vacation for 10 days starting Monday so you might not hear much from me (I have to look into adding Delta-Sigma to a digital Filter Bank during my vacation (short side project - long story, and I won't bore you with details). I am really anxious on getting into the schematic capture with Qt and gdb when I return (maybe Vadim you'll have everything done by then?). Summary: we have all agreed to follow Vadim's QT5 soon to be Master Qucs_S branch? No decision yet on ngspice vs Xyce? I'm leaning to Xyce, except it's installation will be really challenging for students. Does anyone know if spack works on Windows? On OS? I'm Ubuntu with no chance of change but I can always run VirtualBox. Finally, Vadim, any chance you can do another list with order of priority on what you think is more important to be done next?

ra3xdh commented 2 years ago

Hello Kenneth,

I haven't gotten around to figure out how to graph the results yet;

Yes, just place on schematic or display page a digaram component and select desired traces to plot. Also refer to documentation: https://qucs-s-help.readthedocs.io/en/latest/BasSim.html

I am also in the process of trying to get an ADMS generic 22nm EKV model from Christian Enz of EPFL.

The external Verilog-A models (*.va) are now supported only with Qucsator+ADMS combination. The Xyce has experimantal direct support of Verilog-A devices, but it is not implemented in Qucs-S yet. The development of Qucs-S was frozen when this feature was not presented in Xyce.

No decision yet on ngspice vs Xyce

My priority now is the Ngspice support. I have set it as the recommended simulator on the first application run. Ngspice is available in the repositories of the most of modern Linux distributions. Ngspice has the best performance and good compatibility with the component models provided by manufacturers. Also some LTSpice models could be compatible with Ngspice.

kwmartin commented 2 years ago

I totally agree with your thoughts on ngspice, way easier to install; almost certainly preferred for teaching; especially if we ever get to You-Tube courses. Re models: a quote: I also tried using Qucs and NGspice, but finally decided to use LTspice since it includes our EKV model (version 2.6). This is the tool I'm using today for my IC design classes. I'm also developing some Jupyter Notebooks for helping student size simple circuits using our approach with the inversion coefficient. Jupyter Notebook has a package that can run LTspice and collect the data so you can do all your design (sized schematic, no layout) in the Jupyter Notebook. So it looks like what we need is: EKV model (version 2.6) as recommended by the expert! How about you work on ngspice and I'll work on Xyce, and maybe in the end we can have both? Xyce is a bear to install (although spack made an order of difference for me, but I think spack may only work in linux). However, it looks like there may be 5 full-time people supporting Xyce at Sandia Labs (this is huge!) and I have some ideas of being able to hook in mixed mode simulations using Xyce's powerful B sources as the interface without having to change Xyce; this would be a very long term project, but it might work, and if we could get to mixed mode simulation? I could play with lots of interesting things.

kwmartin commented 2 years ago

This is interesting, well worth the time to read: https://xyce.sandia.gov/documentation-tutorials/xyce-adms-users-guide/

tvrusso commented 2 years ago

Xyce is a bear to install (although spack made an order of difference for me, but I think spack may only work in linux).

Xyce is only a "bear" to install because it has a lot of dependencies, one of which is Trilinos, which is a nightmare of its own.

You might look at this repo: https://github.com/tvrusso/XyceBundle

It is a meta package that will build and test Xyce and Trilinos with one command, if you have all the other dependencies installed (on Ubuntu, that's a single "apt install" command, on RHEL a single "yum install" command, and on Cygwin a ton of mouse clicks). The exact set of packages that Xyce and Trilinos depend on is given in the Xyce Building guide in the section on system-specific prerequisites.

Once those dependencies are installed manually, XyceBundle will take care of the rest and leave a usable build of the code in a subdirectory, and you can optionally install it elsewhere. I have successfully used Qucs-s simply by telling it to find the build in the XyceBundle directory.

However, it looks like there may be 5 full-time people supporting Xyce at Sandia Labs (this is huge!)

There are about 8 full time developers, and a few collaborators.

and I have some ideas of being able to hook in mixed mode simulations using Xyce's powerful B sources as the interface without having to change Xyce; this would be a very long term project, but it might work, and if we could get to mixed mode simulation? I could play with lots of interesting things.

There exist methods to hook Xyce up with icarus verilog to do mixed-signal simulation. There's a guide to it on the Xyce documentation and tutorials page. There are even a few examples of how to do it in the Xyce regression suite.

ra3xdh commented 2 years ago

The compact modelling with Qucsator+Adms and Verilog-A modules works using the Qt5 build. But it's need to define the full qucsator executable path and probably make include/qucs-core symlink for include/qucsator. I used qucsator from Ubuntu18.04 PPA package.

ra3xdh commented 2 years ago

The packages for Ubuntu are already available: https://download.opensuse.org/repositories/home:/ra3xdh/xUbuntu_20.04/

ra3xdh commented 2 years ago

QtScript dependency problem resolved by #91

ra3xdh commented 2 years ago

Closing this, because the application code is 100% ported to Qt5 now, including compatibility with Qt5.15 and removing QtScript dependency. Individual issues should be opened if some problems related to Qt5 arise in the future.