libLQ-qt-mc2 with qt4 support
Posted 05-27-2012 at 09:22 PM by rainbowsally
Updated 05-04-2015 at 12:50 PM by rainbowsally (new version)
Updated 05-04-2015 at 12:50 PM by rainbowsally (new version)
Note: As of March 2015, there are 64-bit versions of mc2 and kdevelop3, debugged kdbg, new.make, and more available for d/loading.
See blog entry here if you are running a 64 bit linux.
http://www.linuxquestions.org/questi...-64-bit-36530/
Here's the original post which might contain helpful links if you have trouble finding or linking the Qt libs. There are quite a few versions floating around at this time. :-(
[See note at the bottom IF you have a problem such as:
which you probably won't.
]
This is libLQ with qt support and mc2 (the makefile creator, second generation).
update Sept 27, 2013
http://rainbowsally.org/rainbowsally...x-3.1.3.tar.gz
Uninstall, but keep your old sources (makefile, etc.) in case you don't like the changes. Reworked for debian (linux mint) so you may want to copy your templates folder into the new version. They'll still work.
Here's the previous mc2 and libLQ-qt. (Jan 10, 2013) in case you find it more useful or easier to work with.
http://rainbowsally.org/rainbowsally...-3.0.18.tar.gz
--------------
New to mc2?
To heck with automake. How many times do you have to reconfigure your own files when the configuration doesn't change?
Worse. If you are sharing with folks that have similar setups (not even identical) most if not all of these apps will compile and run with no changes to the makefiles. If you can share an RPM, what are the chances you can't share an mc2 build?
Well... it depends on what you're doing, but for simple stuff it's an easy shot AND it's no worse than any other broken build system, but this one's easy to fix. (In fact so are the OTHER broken build systems with this one.)
Related Apps At The Blog
And if it is necessary to share binaries, you'll need to compile the original files at least once, no?
Once done, then why not 'make' the the binaries from a binary source tree? See new-make, here at the blog. The new-make system is also the installer for the sources for mc2 et. al. if you just want to see what's involved.
New.make creates the file set for the make-based part of the installer.
Here's the program that writes the programs. It installs into ~/bin/src/new-make* so it's easy to edit, not hidden, and automatically set in your path if you have a typical system.
http://www.linuxquestions.org/questi...staller-34641/
Mc2 History:
mc2 is the second generation makefile-creator and has become quite a bit more sophisticated (mostly in the parser algorithm). It was once the reason for the libLQ. Now it needs lib-LQ-qt to work though libLQ-qt has lots of features not used by the mc2 application.
Why The Screwy Paths?
Before you get weird about the screwy installation directory, get used to playing in a sandbox. Do whatever you want, but mc2 will uninstall very cleanly and has two ways to do it.
[Correction: if you use any of the test files or some other features, you might have to delete your ~/.LQ folder. Hidden. It's like a Windows registry key but easily removed. It's not removed automatically by the installer in this version, however.]
Not useful? Boy! You'd better give it a spin before you say that. Finally you can generate makefiles and mess with them and you won't get confused by missing separators or the many other things that makefiles are so sensitive to.
Want a 'real' installation?
mc2 is in no way confined to making sandbox installers and it's (finally) easy to change makefiles and to place the builds in any DANGEROUS place you'd ever want to 'em. ;-)
Get used to playing safe first but when you're ready to do some really risky stuff in the system files, try new-make, UsR2usr, and uncmake, all available here at the blog.
- The Computer Mad Science Team
:-)
re. linkage problem (missing definitions).
I THINK this only happened on my system as I switched back and forth between version 3.0.18 (this d/load) and 3.1.1 (under development) but if this bug does bite you try this:
Type
And then choose which build you really want and 'make install' :-)
That's the easy fix. The problem is with libLQ not uninstalling properly. The only way I can think of that this might happen is if the uninstaller looks in the wrong folder for its files which (again) can only happen between significant versions (not just revs) I'm pretty sure.
In any case, that's the fix if something like that happens to you somehow.
[I'm note sure if the above has been corrected in the latest version or not. I'm not working on mc2 consistently at the moment but I wanted to update the d/load so that if I post any examples, they should work as expected or break at predictable points (such as the lib directories which are different for mint than they were for open[sic]SUSE.]
See blog entry here if you are running a 64 bit linux.
http://www.linuxquestions.org/questi...-64-bit-36530/
Here's the original post which might contain helpful links if you have trouble finding or linking the Qt libs. There are quite a few versions floating around at this time. :-(
[See note at the bottom IF you have a problem such as:
Code:
libLQ-qt.so: undefined reference to `obj_copy_op(char**, char*, char*)' libLQ-qt.so: undefined reference to `obj_delete_op(char*, char*)'
]
This is libLQ with qt support and mc2 (the makefile creator, second generation).
update Sept 27, 2013
http://rainbowsally.org/rainbowsally...x-3.1.3.tar.gz
Uninstall, but keep your old sources (makefile, etc.) in case you don't like the changes. Reworked for debian (linux mint) so you may want to copy your templates folder into the new version. They'll still work.
Here's the previous mc2 and libLQ-qt. (Jan 10, 2013) in case you find it more useful or easier to work with.
http://rainbowsally.org/rainbowsally...-3.0.18.tar.gz
--------------
New to mc2?
To heck with automake. How many times do you have to reconfigure your own files when the configuration doesn't change?
Worse. If you are sharing with folks that have similar setups (not even identical) most if not all of these apps will compile and run with no changes to the makefiles. If you can share an RPM, what are the chances you can't share an mc2 build?
Well... it depends on what you're doing, but for simple stuff it's an easy shot AND it's no worse than any other broken build system, but this one's easy to fix. (In fact so are the OTHER broken build systems with this one.)
Related Apps At The Blog
And if it is necessary to share binaries, you'll need to compile the original files at least once, no?
Once done, then why not 'make' the the binaries from a binary source tree? See new-make, here at the blog. The new-make system is also the installer for the sources for mc2 et. al. if you just want to see what's involved.
New.make creates the file set for the make-based part of the installer.
Here's the program that writes the programs. It installs into ~/bin/src/new-make* so it's easy to edit, not hidden, and automatically set in your path if you have a typical system.
http://www.linuxquestions.org/questi...staller-34641/
Mc2 History:
mc2 is the second generation makefile-creator and has become quite a bit more sophisticated (mostly in the parser algorithm). It was once the reason for the libLQ. Now it needs lib-LQ-qt to work though libLQ-qt has lots of features not used by the mc2 application.
Why The Screwy Paths?
Before you get weird about the screwy installation directory, get used to playing in a sandbox. Do whatever you want, but mc2 will uninstall very cleanly and has two ways to do it.
[Correction: if you use any of the test files or some other features, you might have to delete your ~/.LQ folder. Hidden. It's like a Windows registry key but easily removed. It's not removed automatically by the installer in this version, however.]
Not useful? Boy! You'd better give it a spin before you say that. Finally you can generate makefiles and mess with them and you won't get confused by missing separators or the many other things that makefiles are so sensitive to.
Want a 'real' installation?
mc2 is in no way confined to making sandbox installers and it's (finally) easy to change makefiles and to place the builds in any DANGEROUS place you'd ever want to 'em. ;-)
Get used to playing safe first but when you're ready to do some really risky stuff in the system files, try new-make, UsR2usr, and uncmake, all available here at the blog.
- The Computer Mad Science Team
:-)
re. linkage problem (missing definitions).
I THINK this only happened on my system as I switched back and forth between version 3.0.18 (this d/load) and 3.1.1 (under development) but if this bug does bite you try this:
Type
Code:
make dynamic; make install; make uninstall make static; make install; make uninstall
That's the easy fix. The problem is with libLQ not uninstalling properly. The only way I can think of that this might happen is if the uninstaller looks in the wrong folder for its files which (again) can only happen between significant versions (not just revs) I'm pretty sure.
In any case, that's the fix if something like that happens to you somehow.
[I'm note sure if the above has been corrected in the latest version or not. I'm not working on mc2 consistently at the moment but I wanted to update the d/load so that if I post any examples, they should work as expected or break at predictable points (such as the lib directories which are different for mint than they were for open[sic]SUSE.]
Total Comments 0
