You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
(8) |
May
(2) |
Jun
(4) |
Jul
(6) |
Aug
(3) |
Sep
(11) |
Oct
(23) |
Nov
(12) |
Dec
(14) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(7) |
Feb
(9) |
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(4) |
Dec
|
2005 |
Jan
(6) |
Feb
(25) |
Mar
(9) |
Apr
(17) |
May
(3) |
Jun
(12) |
Jul
(8) |
Aug
(2) |
Sep
(3) |
Oct
|
Nov
|
Dec
(2) |
2006 |
Jan
|
Feb
|
Mar
(44) |
Apr
(4) |
May
(4) |
Jun
|
Jul
(19) |
Aug
(7) |
Sep
(5) |
Oct
(2) |
Nov
(4) |
Dec
(1) |
2007 |
Jan
(12) |
Feb
(23) |
Mar
(9) |
Apr
(9) |
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
(11) |
Oct
(2) |
Nov
(1) |
Dec
(1) |
2008 |
Jan
(9) |
Feb
(1) |
Mar
|
Apr
(1) |
May
(1) |
Jun
(2) |
Jul
(10) |
Aug
(7) |
Sep
(7) |
Oct
(1) |
Nov
(4) |
Dec
|
2009 |
Jan
(2) |
Feb
|
Mar
(2) |
Apr
(1) |
May
(7) |
Jun
|
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
(2) |
Dec
|
2010 |
Jan
(5) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(2) |
Jul
|
Aug
(4) |
Sep
(1) |
Oct
|
Nov
(3) |
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
(4) |
Oct
(13) |
Nov
(7) |
Dec
|
2012 |
Jan
(9) |
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
(1) |
Jul
(2) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
(1) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(3) |
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(6) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
(4) |
Dec
(2) |
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
(7) |
Dec
(19) |
2023 |
Jan
(5) |
Feb
|
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: LaBella, V. <vla...@al...> - 2024-01-26 19:49:41
|
Hi Chris: I just uploaded and tagged the latest version of the manual on github here. https://github.com/vlabella/gle-manual The tag is v4.3.4 to match the release version of GLE. It has all the latest typo fixes. Hope this helps. Vince -----Original Message----- From: Christian T. Steigies <ct...@de...> Sent: Tuesday, January 23, 2024 4:12 PM To: Andrey G. Grozin <A.G...@in...> Cc: Vincent LaBella <lab...@su...>; glx...@li... Subject: Re: [GLE-devel] GLE 4.3.4 Release: linking qgle fails Moin, On Mon, Aug 21, 2023 at 07:47:39PM +0700, Andrey G. Grozin wrote: > gle-4.3.4 (including qgle) builds fine with the attached patch. > > Andrey > diff -r -U2 src.orig/gui/CMakeLists.txt src/gui/CMakeLists.txt > --- src.orig/gui/CMakeLists.txt 2023-04-11 07:46:19.000000000 +0700 > +++ src/gui/CMakeLists.txt 2023-08-21 13:00:21.039704497 +0700 > @@ -70,4 +70,5 @@ > ${PNG_LIBRARIES} > ${PIXMAN_LIBRARIES} > + TIFF::TIFF > Qt::Core > Qt::Gui Thanks for the patch, I did test it already last year, but... Vince already added a similar patch to the github repo, works for me! The new version just got accepted into debian unstable:-) I had to fix a problem with qgle not finding libgs.so: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935720 I am creating a header file during build with the correct path, ie /usr/lib/x86_64-linux-gnu on my AMD64 machine and use this header file with this patch: https://salsa.debian.org/science-team/gle-graphics/-/blob/master/debian/patches/find_gs?ref_type=heads I'd be glad to hear of a better (non debian-specific) solution for this. I also uploaded a current version of the manual. Vince, can we have tags some day when there are propper "releases" of the manual? I just noticed, the version number in the manual seems to be defined by the GLE version that I have installed. So I will probably upload a new manual version everytime a new GLE version is installed. It looks much nicer when the manual has the same version as the installed GLE package. Thanks everybody, keep up the good work! Christian _______________________________________________ Glx-devel mailing list Glx...@li... https://lists.sourceforge.net/lists/listinfo/glx-devel |
From: Christian T. S. <ct...@de...> - 2024-01-23 21:30:58
|
Moin, On Mon, Aug 21, 2023 at 07:47:39PM +0700, Andrey G. Grozin wrote: > gle-4.3.4 (including qgle) builds fine with the attached patch. > > Andrey > diff -r -U2 src.orig/gui/CMakeLists.txt src/gui/CMakeLists.txt > --- src.orig/gui/CMakeLists.txt 2023-04-11 07:46:19.000000000 +0700 > +++ src/gui/CMakeLists.txt 2023-08-21 13:00:21.039704497 +0700 > @@ -70,4 +70,5 @@ > ${PNG_LIBRARIES} > ${PIXMAN_LIBRARIES} > + TIFF::TIFF > Qt::Core > Qt::Gui Thanks for the patch, I did test it already last year, but... Vince already added a similar patch to the github repo, works for me! The new version just got accepted into debian unstable:-) I had to fix a problem with qgle not finding libgs.so: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935720 I am creating a header file during build with the correct path, ie /usr/lib/x86_64-linux-gnu on my AMD64 machine and use this header file with this patch: https://salsa.debian.org/science-team/gle-graphics/-/blob/master/debian/patches/find_gs?ref_type=heads I'd be glad to hear of a better (non debian-specific) solution for this. I also uploaded a current version of the manual. Vince, can we have tags some day when there are propper "releases" of the manual? I just noticed, the version number in the manual seems to be defined by the GLE version that I have installed. So I will probably upload a new manual version everytime a new GLE version is installed. It looks much nicer when the manual has the same version as the installed GLE package. Thanks everybody, keep up the good work! Christian |
From: Andrey G. G. <A.G...@in...> - 2023-08-21 12:47:54
|
gle-4.3.4 (including qgle) builds fine with the attached patch. Andrey |
From: Christian T. S. <ct...@de...> - 2023-04-19 11:00:00
|
Vince, On Tue, Apr 18, 2023 at 05:08:35PM +0000, Vincent LaBella wrote: > Hi Guys: > > I just realized I was building GLE without tiff on linux. I did change it to use TIFF::TIFF and was having trouble with linux so I commented it out. However, it built and linked fine with TIFF on windows and macOS. > > I am away from the computer right now. Did gle link ok with TIFF? Is it just the GUI? Does it have something to do with library order? gle seems to have built fine, with tiff: cts@skeeve:~/src/salsa/gle/gle-graphics-4.3.4/build/gle>ldd gle|grep tiff libtiff.so.5 => /lib/x86_64-linux-gnu/libtiff.so.5 (0x00007fae1a6e2000) I tried putt TIFF::TIFF first in the libraries, but maybe I got confused with the CMakefile. Can I disable TIFF with a switch? Then I could test if qgle builds without tiff, and then figure out if order matters, again. Christian |
From: Vincent L. <lab...@su...> - 2023-04-18 17:42:24
|
Hi Guys: I just realized I was building GLE without tiff on linux. I did change it to use TIFF::TIFF and was having trouble with linux so I commented it out. However, it built and linked fine with TIFF on windows and macOS. I am away from the computer right now. Did gle link ok with TIFF? Is it just the GUI? Does it have something to do with library order? Vince -----Original Message----- From: Christian T. Steigies <ct...@de...> Sent: Tuesday, April 18, 2023 3:10 AM To: Andrey G. Grozin <A.G...@in...> Cc: Vincent LaBella <lab...@su...>; glx...@li... Subject: Re: [GLE-devel] GLE 4.3.4 Release: linking qgle fails On Sat, Apr 15, 2023 at 12:10:56PM +0700, Andrey G. Grozin wrote: > Many undefined references from gletiff.cpp to TIFF<something>. Indeed, > libtiff is absent in this command line. Configure has found > > -- Found TIFF: /usr/lib/libtiff.so (found version "4.5.0") > > But it is not used in linking qgle. The same on Debian. Is it correct to use TIFF::TIFF in the CMakefile instead of TIFF_LIBRARIES as with the JPEG and co? I have tried this, but it dir not work either... https://cmake.org/cmake/help/latest/module/FindTIFF.html Christian |
From: Christian T. S. <ct...@de...> - 2023-04-18 07:37:34
|
On Sat, Apr 15, 2023 at 12:10:56PM +0700, Andrey G. Grozin wrote: > Many undefined references from gletiff.cpp to TIFF<something>. Indeed, > libtiff is absent in this command line. Configure has found > > -- Found TIFF: /usr/lib/libtiff.so (found version "4.5.0") > > But it is not used in linking qgle. The same on Debian. Is it correct to use TIFF::TIFF in the CMakefile instead of TIFF_LIBRARIES as with the JPEG and co? I have tried this, but it dir not work either... https://cmake.org/cmake/help/latest/module/FindTIFF.html Christian |
From: Andrey G. G. <A.G...@in...> - 2023-04-15 05:24:33
|
The failing command is /usr/bin/x86_64-pc-linux-gnu-g++ <options> <many .o files> \ -lz /usr/lib/libpixman-1.so /usr/lib/libcairo.so \ -ldl -lglut -lGLU -lGL \ /usr/lib/libjpeg.so /usr/lib/libpng.so \ /usr/lib/libpixman-1.so /usr/lib/libcairo.so \ -ldl -lglut -lGLU -lGL \ /usr/lib64/libQt5Network.so.5.15.8 /usr/lib64/libQt5OpenGL.so.5.15.8 \ /usr/lib64/libQt5Widgets.so.5.15.8 /usr/lib64/libQt5Gui.so.5.15.8 \ /usr/lib64/libQt5Core.so.5.15.8 Many undefined references from gletiff.cpp to TIFF<something>. Indeed, libtiff is absent in this command line. Configure has found -- Found TIFF: /usr/lib/libtiff.so (found version "4.5.0") But it is not used in linking qgle. Andrey |
From: Vincent L. <lab...@su...> - 2023-04-11 12:54:16
|
Hello Everyone: I am happy to announce that a new release of GLE 4.3.4 has just been uploaded to SourceForge and GitHub. https://glx.sourceforge.net/downloads/downloads.html https://github.com/vlabella/GLE This release has the following improvements. Special thanks to everyone who contributed. 4.3.4 (April 2023) - built with latest compilers and libraries on all platforms (boost 1.81.0, qt 5.15.8, et al.) - added numrows feature to graph data command to limit number of data rows read (R. Machulka) - added shortcut operators += -= *= /= ++ -- (V. LaBella) - improvements to feyn.gle package (A. Grozin) - clarifications and improvements to manual (V. LaBella, A. Grozin) - build improvements with cmake, will find ztd and jbig for libtiff if available, and other OS specific tweaks (V. LaBella, C. Steigies, A. Grozin, adalbosco) Enjoy, Vincent LaBella |
From: Christian T. S. <ct...@de...> - 2023-01-08 17:11:13
|
Happy New Year, On Tue, Jan 03, 2023 at 08:42:43PM +0000, Vincent LaBella wrote: > Happy New Year Christian and Andrey: > > Regarding creation of inittex.ini: > > - It is created during the installation phase of cmake That did not work for me. IIRC in the installation phase only qgle got installed. So for the debian package I now skip the installation phase and pick the compiled binaries by-hand. I did add building of inittex.ini to the debuild build process, works fine. I wouldn't mind, though, if cmake install took care of all this, but its not urgent right now. > Still no network at school and classes are starting in two weeks. IT needs to go around and install Antivirus software on everyone's computer - hopefully there is a linux version. I am still waiting - hopefully this week. I really wanted to use this time to review the pull requests and get a new release out that rolls up all our recent changes. A day after your message I could not reach our Uni network either... fortunately it was just an old switch. But its getting scarier every day. In the Debian package I removed the warning about the register keyword with this patch: https://salsa.debian.org/science-team/gle-graphics/-/blob/master/debian/patches/no_register If I figure out again how to create the pull request, I will create one. I also dropped the no-pie option. I am wondering if I want to change the install location of the gle manual to /usr/share/doc/gle-graphics instead of /usr/share/gle-graphics/doc. I assume that only qgle needs to know about the location of the PDF? I think the gle-graphics is fine for the next debian release now (I just need to upload the two new packages to unstable instead of experimental). For the version numbers of gle-library and gle-manual I picked the date of the last commit, but I can change that if you decide to pick another versioning scheme. If you don't want to use version numbers, some tags (with the date instead of a version?) would be nice, though, so the debian tools can automatically notify when a new version is available. Christian |
From: Vincent L. <lab...@su...> - 2023-01-03 20:43:00
|
Happy New Year Christian and Andrey: Regarding creation of inittex.ini: - It is created during the installation phase of cmake - it uses the binary located at ${CMAKE_INSTALL_PREFIX}/bin -see src/TeX/CmakeLists.txt for command - if you set CMAKE_INSTALL_PREFIX to some other location than system default such as a staging area like I do then it will call the gle that was just compiled and not the global system one - at one time I had initex.ini being made during the build phase - see commented code in cmake file. I forget exactly why I switched to install phase - but I can move it back. Still no network at school and classes are starting in two weeks. IT needs to go around and install Antivirus software on everyone's computer - hopefully there is a linux version. I am still waiting - hopefully this week. I really wanted to use this time to review the pull requests and get a new release out that rolls up all our recent changes. Vince -----Original Message----- From: Andrey G. Grozin <A.G...@in...> Sent: Monday, January 2, 2023 11:38 PM To: Christian T. Steigies <ct...@de...> Cc: Vincent LaBella <lab...@su...>; glx...@li... Subject: Re: [GLE-devel] installation On Mon, 2 Jan 2023, Christian T. Steigies wrote: > However, the manual > makes use of inittex.ini, which is not in the gle-graphics package > (was not created by the cmake run). It can be easily created with gle > -mkinittex but only as root, since it tries to write the file into the GLE_TOP_DIR folder. > If I don't set that and run it as regular user, it can not write there > and gle segfaults! Is inittex.ini useful for anything else besides the manual? Yes! It is needed for ordinary users every time they use the command tex "$x+y$" in their gle scripts (or begin tex ... end tex). > I either need to create this when building the package, or, very > simply, during installation, but I am not sure if its a good idea to > create this file on the fly during installation. Im my Gentoo package (ebuild) I generate inittex.ini during the building stage, alongside with the cmake machinery. In fact, cmake is trying to generate it, but this place in CMakeLists.txt is buggy. If gle is already installed on the computer I'm using to build the new gle (it may be an older version), then cmake calls this already installed gle instead of the freshly compiled one. This old gle tries to write to /usr/share/gle/..., and the build fails. So, I had to comment out this place in CMakeLists.txt, and to produce inittex.ini by hand after cmake. > It its only needed for building the > manual, I would like to move creating the file to the manual package. It is needed for end users for their regular work. > I tried enabling poppler and manip, but it did not work out yet. Will > this still be worked on or is this obsolete? Patches are here: > https://salsa.debian.org/science-team/gle-graphics/-/tree/master/debia > n/patches I have an impression that in the new version they are incorporated in gle itself. Am I right? Andrey |
From: Christian T. S. <ct...@de...> - 2023-01-03 17:37:36
|
On Tue, Jan 03, 2023 at 11:38:22AM +0700, Andrey G. Grozin wrote: > On Mon, 2 Jan 2023, Christian T. Steigies wrote: > > However, the manual > > makes use of inittex.ini, which is not in the gle-graphics package (was not > > created by the cmake run). It can be easily created with gle -mkinittex but > > only as root, since it tries to write the file into the GLE_TOP_DIR > > folder. If I don't set that and run it as regular user, it can not write > > there and > > gle segfaults! Is inittex.ini useful for anything else besides the manual? > Yes! It is needed for ordinary users every time they use the command > > tex "$x+y$" > > in their gle scripts (or begin tex ... end tex). Oh, ok, then this has to be included in the package, thanks. > > I tried enabling poppler and manip, but it did not work out yet. Will this > > still be worked on or is this obsolete? Patches are here: > > https://salsa.debian.org/science-team/gle-graphics/-/tree/master/debian/patches > I have an impression that in the new version they are incorporated in gle > itself. Am I right? The patches? Some of them, depends on which Vincent accepts. One patch (remove_dynamic_exception_specifications) is already included in the git repo. Your makefmt patch will probably be included as well. With the other patches, I don't know if they work on other systems than debian/linux or not. fix_qgle could be at least partially included as it solves the linking problem. But I also disabled Wayland integration and changed the path to the ghostscript libraries, which may be Debian specific. I replaced FindCairo and FindPixman by external cmake files which work for me, but, it seems, were not needed for Windows. So if others find these patches useful, just include them or ask Vincent to include them upstream. Otherwise I will just keep them as Debian specific patches. Christian |
From: Andrey G. G. <A.G...@in...> - 2023-01-03 04:38:36
|
On Mon, 2 Jan 2023, Christian T. Steigies wrote: > However, the manual > makes use of inittex.ini, which is not in the gle-graphics package (was not > created by the cmake run). It can be easily created with gle -mkinittex but > only as root, since it tries to write the file into the GLE_TOP_DIR folder. > If I don't set that and run it as regular user, it can not write there and > gle segfaults! Is inittex.ini useful for anything else besides the manual? Yes! It is needed for ordinary users every time they use the command tex "$x+y$" in their gle scripts (or begin tex ... end tex). > I either need to create this when building the package, or, very simply, > during installation, but I am not sure if its a good idea to create this > file on the fly during installation. Im my Gentoo package (ebuild) I generate inittex.ini during the building stage, alongside with the cmake machinery. In fact, cmake is trying to generate it, but this place in CMakeLists.txt is buggy. If gle is already installed on the computer I'm using to build the new gle (it may be an older version), then cmake calls this already installed gle instead of the freshly compiled one. This old gle tries to write to /usr/share/gle/..., and the build fails. So, I had to comment out this place in CMakeLists.txt, and to produce inittex.ini by hand after cmake. > It its only needed for building the > manual, I would like to move creating the file to the manual package. It is needed for end users for their regular work. > I tried enabling poppler and manip, but it did not work out yet. Will this > still be worked on or is this obsolete? Patches are here: > https://salsa.debian.org/science-team/gle-graphics/-/tree/master/debian/patches I have an impression that in the new version they are incorporated in gle itself. Am I right? Andrey |
From: Christian T. S. <ct...@de...> - 2023-01-02 15:38:32
|
Hi, I have uploaded GLE 4.3.3 to Debian experimental with the changes I mentioned. The gle-graphics package produces a second deb with just glebtool, as that binary is only used for building the manual. Is that correct? I never included glebtool in the debian package before, but the file is only around 100kb, so I wonder if it makes sense to create a separate package for this (which causes a bit of overhead with README and copyright, and a nearly empty manpage). During the build for experimental I get a lot of new warnings like these: /srv/build/gle-graphics-4.3.3/src/makefmt/parseAFM.cpp:858:20: warning: ISO C++17 does not allow ‘register’ storage class specifier [-Wregister] register char *keyword; I guess this needs to be fixed for the next Debian release. The gle-library is packaged separately as gle-graphics-library. There are no binaries in this package, some of the included files are used for building the manual, which I intend to package next. However, the manual makes use of inittex.ini, which is not in the gle-graphics package (was not created by the cmake run). It can be easily created with gle -mkinittex but only as root, since it tries to write the file into the GLE_TOP_DIR folder. If I don't set that and run it as regular user, it can not write there and gle segfaults! Is inittex.ini useful for anything else besides the manual? I either need to create this when building the package, or, very simply, during installation, but I am not sure if its a good idea to create this file on the fly during installation. It its only needed for building the manual, I would like to move creating the file to the manual package. I tried enabling poppler and manip, but it did not work out yet. Will this still be worked on or is this obsolete? Patches are here: https://salsa.debian.org/science-team/gle-graphics/-/tree/master/debian/patches Christian |
From: Christian T. S. <ct...@de...> - 2022-12-29 13:37:57
|
Hi, On Sat, Dec 24, 2022 at 05:25:52PM +0700, Andrey G. Grozin wrote: > > I have an impression that doing all this stuff is the direct duty of cmake, > but I had to struggle against it - to copy various files from several > different places to the installation image. Funnily, exactly 1 file is > installed by cmake to its intended destination: it is qgle. I can confirm all(most?) of these findings for Debian. I have been picking files from the build directly for the debian package, and wondered why I ended up with two copies of qgle... only qgle is installed by cmake. cmake -P build/cmake_install.cmake -- Install configuration: "" -- Up-to-date: /home/cts/src/gle-graphics-4.3.3/local/bin/qgle So I guess I skip the install part and pick everything from the build dir. Lets see if I can find all the files from the previous version (ini.tex and co), but I agree, I think this should be the job of cmake. No problem for building a debian package, though (if I ignore cmake's install capabilities, because that was messing with my directory structure). I do miss poppler support, though. I tried to enable it, see the attached poppler patch. I don't think adding the include directories manually is the correct way to do it, and it did not work in the end (and is arch specific, which is not good)... Also missing is manip. Simply enabling it in the CMakeLists.txt fails: /home/cts/src/gle-graphics-4.3.3/src/manip/unix_extra.cpp: In function ‘int findfirst(char*, ffblk*, int)’: /home/cts/src/gle-graphics-4.3.3/src/manip/unix_extra.cpp:95:2: error: ‘waitpid’ was not declared in this scope 95 | waitpid(p,&status,op); | ^~~~~~~ make[3]: *** [manip/CMakeFiles/manip.dir/build.make:264: manip/CMakeFiles/manip.dir/unix_extra.cpp.o] Error 1 As for the GLE_TOP workaround, I simply hardcode the path, see gle_top. It works for me, but it would be better to be able set GLE_TOP with a compile time option, as the version number changes every release and the patch would have to be updated then. The manual does not build (yet). I guess I first need to install the files from gle-library. And then it uses glebtool? That is not available in the debian package, so gle-manual can not be built independently of gle? gle -d pdf -o tt.pdf font-table.gle tt GLE 4.3.3[font-table.gle]-C-R-[tt][.eps][.pdf] ../../build/bin/glebtool -latexdef extrafonts.tex extrafonts make[1]: ../../build/bin/glebtool: No such file or directory make[1]: *** [Makefile.gcc:71: extrafonts.tex] Error 127 make[1]: Leaving directory '/home/cts/src/github/vlabella/gle-manual/fonttest' Other than that, I get a working Debian package. Peace, Christian |
From: Andrey G. G. <A.G...@in...> - 2022-12-24 10:26:26
|
On Wed, 21 Dec 2022, Vincent LaBella wrote: > the goal of the install commands in cmake is to produce the _exect_ > folder and file location that would occur if the program where installed > using an install script or installer. Yes, my goal is exactly the same. However, I achieve it not with the help of cmake, but struggling with cmake. After the firststep - installation to the install image /var/tmp/portage/sci-visualization/gle-4.3.3-r3/image I get the directory usr there: bilbo image # tree usr usr ├── bin │ ├── gle │ ├── gle.bin │ └── qgle └── share ├── doc │ └── gle-4.3.3-r3 │ ├── ChangeLog.txt.bz2 │ ├── gle-manual.pdf │ └── README.txt.bz2 ├── emacs │ └── site-lisp │ ├── gle │ │ ├── gle-mode.el │ │ └── gle-mode.elc │ └── site-gentoo.d │ └── 64gle-gentoo.el └── gle ├── font │ ├── arial8.fmt │ ├── arialbd8.fmt │ ├── arialbi8.fmt │ ├── ariali8.fmt │ ├── cokoi8b.fmt │ ├── cokoi8bi.fmt │ ├── cokoi8i.fmt │ ├── cokoi8n.fmt │ ├── font.dat │ ├── glemark.fmt │ ├── glemark.fve │ ├── plba.fmt │ ├── plba.fve │ ├── plcc.fmt │ ├── plcc.fve │ ├── plcg.fmt │ ├── plcg.fve │ ├── plci.fmt │ ├── plci.fve │ ├── plcr.fmt │ ├── plcr.fve │ ├── plcs.fmt │ ├── plcs.fve │ ├── pldr.fmt │ ├── pldr.fve │ ├── plge.fmt │ ├── plge.fve │ ├── plgg.fmt │ ├── plgg.fve │ ├── plgi.fmt │ ├── plgi.fve │ ├── plsa.fmt │ ├── plsa.fve │ ├── plsg.fmt │ ├── plsg.fve │ ├── plsr.fmt │ ├── plsr.fve │ ├── plss.fmt │ ├── plss.fve │ ├── plsym1.fmt │ ├── plsym1.fve │ ├── plsym2.fmt │ ├── plsym2.fve │ ├── plti.fmt │ ├── plti.fve │ ├── pltr.fmt │ ├── pltr.fve │ ├── psagb.fmt │ ├── psagbo.fmt │ ├── psagd.fmt │ ├── psagdo.fmt │ ├── psbd.fmt │ ├── psbdi.fmt │ ├── psbl.fmt │ ├── psbli.fmt │ ├── pscb.fmt │ ├── pscbo.fmt │ ├── psc.fmt │ ├── psco.fmt │ ├── psfont.dat │ ├── pshb.fmt │ ├── pshbo.fmt │ ├── pshcb.fmt │ ├── pshcbo.fmt │ ├── pshcdo.fmt │ ├── pshc.fmt │ ├── psh.fmt │ ├── pshnb.fmt │ ├── pshnbo.fmt │ ├── pshn.fmt │ ├── pshno.fmt │ ├── psho.fmt │ ├── psncsb.fmt │ ├── psncsbi.fmt │ ├── psncsi.fmt │ ├── psncsr.fmt │ ├── pspb.fmt │ ├── pspbi.fmt │ ├── pspi.fmt │ ├── pspr.fmt │ ├── pssym.fmt │ ├── pstb.fmt │ ├── pstbi.fmt │ ├── psti.fmt │ ├── pstr.fmt │ ├── pszcmi.fmt │ ├── pszd.fmt │ ├── texcmb.fmt │ ├── texcmb.fve │ ├── texcmex.fmt │ ├── texcmex.fve │ ├── texcmitt.fmt │ ├── texcmitt.fve │ ├── texcmmi.fmt │ ├── texcmmi.fve │ ├── texcmr.fmt │ ├── texcmr.fve │ ├── texcmsl.fmt │ ├── texcmssb.fmt │ ├── texcmssb.fve │ ├── texcmss.fmt │ ├── texcmss.fve │ ├── texcmssi.fmt │ ├── texcmssi.fve │ ├── texcmsy.fmt │ ├── texcmsy.fve │ ├── texcmti.fmt │ ├── texcmti.fve │ ├── texcmtt.fmt │ ├── texcmtt.fve │ ├── times8.fmt │ ├── timesbd8.fmt │ ├── timesbi8.fmt │ └── timesi8.fmt ├── gleinc │ ├── barcode.gle │ ├── barstyles.gle │ ├── color.gle │ ├── compat │ │ └── colors-gle-4.0.12.gle │ ├── compatibility.gle │ ├── contour.gle │ ├── electronics.gle │ ├── ellipse.gle │ ├── feyn.gle │ ├── graphutil.gle │ ├── include_en.gle │ ├── matrix_3D.gle │ ├── piesub.gle │ ├── polarplot.gle │ ├── shape.gle │ ├── simpletree.gle │ ├── stm.gle │ ├── tree.gle │ └── ziptext.gle ├── glerc ├── init.tex └── inittex.ini 12 directories, 145 files This is exactly the directory structure which will be copied to the real /usr directory of an end-user. However, I had to do several things to achieve thes goal. 1. cmake usually uses out-of-source build, and this is good. So, after building gle I get the directory /var/tmp/portage/sci-visualization/gle-4.3.3-r3/work/gle-4.3.3_build with the content bilbo work # tree gle-4.3.3_build/ gle-4.3.3_build/ ├── build.ninja ├── CMakeCache.txt ├── CMakeFiles │ ├── 3.25.1 │ │ ├── CMakeCCompiler.cmake │ │ ├── CMakeCXXCompiler.cmake │ │ ├── CMakeDetermineCompilerABI_C.bin │ │ ├── CMakeDetermineCompilerABI_CXX.bin │ │ ├── CMakeSystem.cmake │ │ ├── CompilerIdC │ │ │ ├── a.out │ │ │ ├── CMakeCCompilerId.c │ │ │ └── tmp │ │ └── CompilerIdCXX │ │ ├── a.out │ │ ├── CMakeCXXCompilerId.cpp │ │ └── tmp │ ├── clean_additional.cmake │ ├── cmake.check_cache │ ├── CMakeError.log │ ├── CMakeOutput.log │ ├── CMakeScratch │ ├── d │ │ └── 845944d9b84cbce14d22223ea0563a8d1a541e01db71ab68c220b79ae7878e40.d │ ├── pkgRedirects │ ├── rules.ninja │ └── TargetDirectories.txt ├── cmake_install.cmake ├── CPackConfig.cmake ├── CPackSourceConfig.cmake ├── fbuild │ ├── CMakeFiles │ │ └── fbuild.dir │ │ ├── __ │ │ │ └── gle │ │ │ ├── cutils.cpp.o │ │ │ ├── file_io.cpp.o │ │ │ └── token.cpp.o │ │ └── fbuild.cpp.o │ ├── cmake_install.cmake │ └── fbuild ├── fonts │ ├── CMakeFiles │ └── cmake_install.cmake ├── gentoo_common_config.cmake ├── gentoo_rules.cmake ├── gentoo_toolchain.cmake ├── gle │ ├── CMakeFiles │ │ ├── gle_common.dir │ │ │ ├── axis.cpp.o │ │ │ ├── begin.cpp.o │ │ │ ├── bitmap │ │ │ │ ├── ascii85.cpp.o │ │ │ │ ├── glegif.cpp.o │ │ │ │ ├── glejpeg.cpp.o │ │ │ │ ├── glepng.cpp.o │ │ │ │ ├── gletiff.cpp.o │ │ │ │ ├── img2ps.cpp.o │ │ │ │ └── lzwencode.cpp.o │ │ │ ├── b_tab.cpp.o │ │ │ ├── b_text.cpp.o │ │ │ ├── builtin-double.cpp.o │ │ │ ├── cmdline.cpp.o │ │ │ ├── color.cpp.o │ │ │ ├── config.cpp.o │ │ │ ├── core.cpp.o │ │ │ ├── curve.cpp.o │ │ │ ├── cutils.cpp.o │ │ │ ├── d_cairo.cpp.o │ │ │ ├── d_dummy.cpp.o │ │ │ ├── d_ps.cpp.o │ │ │ ├── drawit.cpp.o │ │ │ ├── d_svg.cpp.o │ │ │ ├── d_x.cpp.o │ │ │ ├── eval.cpp.o │ │ │ ├── file_io.cpp.o │ │ │ ├── fitbez.cpp.o │ │ │ ├── fitcf.cpp.o │ │ │ ├── fn.cpp.o │ │ │ ├── font.cpp.o │ │ │ ├── general.cpp.o │ │ │ ├── glearray.cpp.o │ │ │ ├── gle-base.cpp.o │ │ │ ├── gle-block.cpp.o │ │ │ ├── gle-datatype.cpp.o │ │ │ ├── gle-interface.cpp.o │ │ │ ├── gle-poppler.cpp.o │ │ │ ├── gle-sourcefile.cpp.o │ │ │ ├── gprint.cpp.o │ │ │ ├── graph2.cpp.o │ │ │ ├── graph.cpp.o │ │ │ ├── key.cpp.o │ │ │ ├── keyword.cpp.o │ │ │ ├── leastsq.cpp.o │ │ │ ├── letzfitz │ │ │ │ ├── ffit.cpp.o │ │ │ │ ├── fit.cpp.o │ │ │ │ └── let.cpp.o │ │ │ ├── memory.cpp.o │ │ │ ├── mychar.cpp.o │ │ │ ├── numberformat.cpp.o │ │ │ ├── op_def.cpp.o │ │ │ ├── pass.cpp.o │ │ │ ├── polish.cpp.o │ │ │ ├── run.cpp.o │ │ │ ├── savgol.cpp.o │ │ │ ├── specialfunctions.cpp.o │ │ │ ├── sub.cpp.o │ │ │ ├── surface │ │ │ │ ├── fcontour.cpp.o │ │ │ │ ├── ffitcontour.cpp.o │ │ │ │ ├── gcontour.cpp.o │ │ │ │ ├── gsurface.cpp.o │ │ │ │ └── hide.cpp.o │ │ │ ├── tex.cpp.o │ │ │ ├── texinterface.cpp.o │ │ │ ├── token.cpp.o │ │ │ ├── tokens │ │ │ │ ├── BinIO.cpp.o │ │ │ │ ├── StringKeyHash.cpp.o │ │ │ │ └── Tokenizer.cpp.o │ │ │ └── var.cpp.o │ │ ├── gle.dir │ │ │ └── gle.cpp.o │ │ ├── libgle-graphics.dir │ │ │ └── gle_cpp_lib.cpp.o │ │ └── libgle-graphics_s.dir │ │ └── gle_cpp_lib.cpp.o │ ├── cmake_install.cmake │ ├── font │ │ ├── arial8.fmt │ │ ├── arialbd8.fmt │ │ ├── arialbi8.fmt │ │ ├── ariali8.fmt │ │ ├── cokoi8b.fmt │ │ ├── cokoi8bi.fmt │ │ ├── cokoi8i.fmt │ │ ├── cokoi8n.fmt │ │ ├── font.dat │ │ ├── glemark.fmt │ │ ├── glemark.fve │ │ ├── plba.fmt │ │ ├── plba.fve │ │ ├── plcc.fmt │ │ ├── plcc.fve │ │ ├── plcg.fmt │ │ ├── plcg.fve │ │ ├── plci.fmt │ │ ├── plci.fve │ │ ├── plcr.fmt │ │ ├── plcr.fve │ │ ├── plcs.fmt │ │ ├── plcs.fve │ │ ├── pldr.fmt │ │ ├── pldr.fve │ │ ├── plge.fmt │ │ ├── plge.fve │ │ ├── plgg.fmt │ │ ├── plgg.fve │ │ ├── plgi.fmt │ │ ├── plgi.fve │ │ ├── plsa.fmt │ │ ├── plsa.fve │ │ ├── plsg.fmt │ │ ├── plsg.fve │ │ ├── plsr.fmt │ │ ├── plsr.fve │ │ ├── plss.fmt │ │ ├── plss.fve │ │ ├── plsym1.fmt │ │ ├── plsym1.fve │ │ ├── plsym2.fmt │ │ ├── plsym2.fve │ │ ├── plti.fmt │ │ ├── plti.fve │ │ ├── pltr.fmt │ │ ├── pltr.fve │ │ ├── psagb.fmt │ │ ├── psagbo.fmt │ │ ├── psagd.fmt │ │ ├── psagdo.fmt │ │ ├── psbd.fmt │ │ ├── psbdi.fmt │ │ ├── psbl.fmt │ │ ├── psbli.fmt │ │ ├── pscb.fmt │ │ ├── pscbo.fmt │ │ ├── psc.fmt │ │ ├── psco.fmt │ │ ├── psfont.dat │ │ ├── pshb.fmt │ │ ├── pshbo.fmt │ │ ├── pshcb.fmt │ │ ├── pshcbo.fmt │ │ ├── pshcdo.fmt │ │ ├── pshc.fmt │ │ ├── psh.fmt │ │ ├── pshnb.fmt │ │ ├── pshnbo.fmt │ │ ├── pshn.fmt │ │ ├── pshno.fmt │ │ ├── psho.fmt │ │ ├── psncsb.fmt │ │ ├── psncsbi.fmt │ │ ├── psncsi.fmt │ │ ├── psncsr.fmt │ │ ├── pspb.fmt │ │ ├── pspbi.fmt │ │ ├── pspi.fmt │ │ ├── pspr.fmt │ │ ├── pssym.fmt │ │ ├── pstb.fmt │ │ ├── pstbi.fmt │ │ ├── psti.fmt │ │ ├── pstr.fmt │ │ ├── pszcmi.fmt │ │ ├── pszd.fmt │ │ ├── texcmb.fmt │ │ ├── texcmb.fve │ │ ├── texcmex.fmt │ │ ├── texcmex.fve │ │ ├── texcmitt.fmt │ │ ├── texcmitt.fve │ │ ├── texcmmi.fmt │ │ ├── texcmmi.fve │ │ ├── texcmr.fmt │ │ ├── texcmr.fve │ │ ├── texcmsl.fmt │ │ ├── texcmssb.fmt │ │ ├── texcmssb.fve │ │ ├── texcmss.fmt │ │ ├── texcmss.fve │ │ ├── texcmssi.fmt │ │ ├── texcmssi.fve │ │ ├── texcmsy.fmt │ │ ├── texcmsy.fve │ │ ├── texcmti.fmt │ │ ├── texcmti.fve │ │ ├── texcmtt.fmt │ │ ├── texcmtt.fve │ │ ├── times8.fmt │ │ ├── timesbd8.fmt │ │ ├── timesbi8.fmt │ │ └── timesi8.fmt │ ├── gle │ ├── glerc │ ├── liblibgle-graphics_s.a │ └── liblibgle-graphics.so ├── glebtool │ ├── CMakeFiles │ │ └── glebtool.dir │ │ ├── __ │ │ │ └── gle │ │ │ ├── cutils.cpp.o │ │ │ └── file_io.cpp.o │ │ └── glebtool.cpp.o │ ├── cmake_install.cmake │ └── glebtool ├── gui │ ├── CMakeFiles │ │ ├── qgle_autogen.dir │ │ │ ├── AutogenInfo.json │ │ │ ├── AutogenUsed.txt │ │ │ ├── AutoRcc_qgle_EWIEGA46WW_Info.json │ │ │ ├── AutoRcc_qgle_EWIEGA46WW_Lock.lock │ │ │ ├── AutoRcc_qgle_EWIEGA46WW_Used.txt │ │ │ └── ParseCache.txt │ │ └── qgle.dir │ │ ├── 3dviewer.cpp.o │ │ ├── about.cpp.o │ │ ├── amove.cpp.o │ │ ├── arc.cpp.o │ │ ├── circle.cpp.o │ │ ├── colourbutton.cpp.o │ │ ├── colourpicker.cpp.o │ │ ├── component.cpp.o │ │ ├── consolewindow.cpp.o │ │ ├── dialogues.cpp.o │ │ ├── drawingobject.cpp.o │ │ ├── ellipse.cpp.o │ │ ├── fileinfo.cpp.o │ │ ├── gledrawing.cpp.o │ │ ├── grid.cpp.o │ │ ├── line.cpp.o │ │ ├── main.cpp.o │ │ ├── mainwindow.cpp.o │ │ ├── newfile.cpp.o │ │ ├── objectblocks.cpp.o │ │ ├── polararray.cpp.o │ │ ├── propertyeditor.cpp.o │ │ ├── propertymodel.cpp.o │ │ ├── qgle_autogen │ │ │ ├── EWIEGA46WW │ │ │ │ └── qrc_qgle.cpp.o │ │ │ └── mocs_compilation.cpp.o │ │ ├── qgle_statics.cpp.o │ │ ├── qgs.cpp.o │ │ ├── qgslibloader.cpp.o │ │ ├── serverthread.cpp.o │ │ ├── settings.cpp.o │ │ ├── settings_dialogue.cpp.o │ │ ├── snapline.cpp.o │ │ ├── text.cpp.o │ │ └── variantdelegate.cpp.o │ ├── cmake_install.cmake │ ├── qgle │ └── qgle_autogen │ ├── deps │ ├── EWIEGA46WW │ │ ├── moc_3dviewer.cpp │ │ ├── moc_3dviewer.cpp.d │ │ ├── moc_about.cpp │ │ ├── moc_about.cpp.d │ │ ├── moc_amove.cpp │ │ ├── moc_amove.cpp.d │ │ ├── moc_arc.cpp │ │ ├── moc_arc.cpp.d │ │ ├── moc_circle.cpp │ │ ├── moc_circle.cpp.d │ │ ├── moc_colourbutton.cpp │ │ ├── moc_colourbutton.cpp.d │ │ ├── moc_colourpicker.cpp │ │ ├── moc_colourpicker.cpp.d │ │ ├── moc_component.cpp │ │ ├── moc_component.cpp.d │ │ ├── moc_consolewindow.cpp │ │ ├── moc_consolewindow.cpp.d │ │ ├── moc_dialogues.cpp │ │ ├── moc_dialogues.cpp.d │ │ ├── moc_drawingobject.cpp │ │ ├── moc_drawingobject.cpp.d │ │ ├── moc_ellipse.cpp │ │ ├── moc_ellipse.cpp.d │ │ ├── moc_gledrawing.cpp │ │ ├── moc_gledrawing.cpp.d │ │ ├── moc_grid.cpp │ │ ├── moc_grid.cpp.d │ │ ├── moc_line.cpp │ │ ├── moc_line.cpp.d │ │ ├── moc_mainwindow.cpp │ │ ├── moc_mainwindow.cpp.d │ │ ├── moc_newfile.cpp │ │ ├── moc_newfile.cpp.d │ │ ├── moc_objectblocks.cpp │ │ ├── moc_objectblocks.cpp.d │ │ ├── moc_polararray.cpp │ │ ├── moc_polararray.cpp.d │ │ ├── moc_propertyeditor.cpp │ │ ├── moc_propertyeditor.cpp.d │ │ ├── moc_propertymodel.cpp │ │ ├── moc_propertymodel.cpp.d │ │ ├── moc_qgs.cpp │ │ ├── moc_qgs.cpp.d │ │ ├── moc_serverthread.cpp │ │ ├── moc_serverthread.cpp.d │ │ ├── moc_settings.cpp │ │ ├── moc_settings.cpp.d │ │ ├── moc_settings_dialogue.cpp │ │ ├── moc_settings_dialogue.cpp.d │ │ ├── moc_snapline.cpp │ │ ├── moc_snapline.cpp.d │ │ ├── moc_text.cpp │ │ ├── moc_text.cpp.d │ │ ├── moc_variantdelegate.cpp │ │ ├── moc_variantdelegate.cpp.d │ │ └── qrc_qgle.cpp │ ├── include │ ├── moc_predefs.h │ ├── mocs_compilation.cpp │ └── timestamp ├── makefmt │ ├── CMakeFiles │ │ └── makefmt.dir │ │ ├── __ │ │ │ └── gle │ │ │ ├── cutils.cpp.o │ │ │ └── file_io.cpp.o │ │ ├── makefmt.cpp.o │ │ └── parseAFM.cpp.o │ ├── cmake_install.cmake │ └── makefmt └── TeX ├── CMakeFiles └── cmake_install.cmake 48 directories, 337 files Then I copy gle/gle -> .../bin/gle.bin (why? explained later) gui/qgle -> .../bin/ gle/glerc -> .../share/gle/ gle/font -> .../share/gle where ... means /var/tmp/portage/sci-visualization/gle-4.3.3-r3/image 2. I copy files from /var/tmp/portage/sci-visualization/gle-4.3.3-r3/work/gle-library-d476418f006b001dc7f47dcafb413c0557fa44a7/include/ (this is a snapshot of gle-library in github) to .../share/gle/gleinc/ 3. I install .../bin/gle: #!/bin/sh export GLE_TOP=/usr/share/gle exec /usr/bin/gle.bin $* I *have* to inform the gle binary that its data files (of an end-user's sustem) are in /usr/share/gle/, so, there seems to be no way to avoid this shell wrapper. 4. The next files are absent in the cmake build directory gle-4.3.3_build, so, I have to install them fron the source tree /var/tmp/portage/sci-visualization/gle-4.3.3-r3/work/GLE-4.3.3/ src/TeX/init.tex -> .../share/gle/ doc/README.txt, doc/ChangeLog.txt -> .../share/doc/gle-4.3.3-r3/ 5. I've commented out install(CODE "execute_process(COMMAND ${CMAKE_INSTALL_PREFIX}/bin/gle$<$<CONFIG:Debug>:d> -mkinittex)") in CMakeLists.txt because (I have no idea why) the previously installed gle was called, not the freshly compiled one. So, I run .../bin/gle.bin -mkinittex (after setting the appropriate GLE_TOP). 6. I install gle-manual.pdf (a copy from the Gentoo repository - the file at glx.sourceforge. io can unpredictably change at any moment, and then the checksum checking will fail for the end-user) -> .../share/doc/gle-4.3.3-r3/ 7. I install emacs-related stuff (also a snapshot). I have an impression that doing all this stuff is the direct duty of cmake, but I had to struggle against it - to copy various files from several different places to the installation image. Funnily, exactly 1 file is installed by cmake to its intended destination: it is qgle. Merry Christmas, Andrey |
From: Vincent L. <lab...@su...> - 2022-12-22 00:21:16
|
Andrey: Again thanks for all the effort on this. I will search for the man page. I think it might still be in the sourceforge git repo. Unfortunately our campus got cyber attacked last week and the whole network is down. None of my stuff was affected but it is nevertheless not connected to the internet so I cannot do much. It might be another week or two until we are back online. It would be good to get gle building correctly using cmake on as many platforms as possible so I look forward to the pull request. Happy Holidays Vince -----Original Message----- From: Andrey G. Grozin <A.G...@in...> Sent: Wednesday, December 21, 2022 11:24 AM To: glx...@li... Cc: Vincent LaBella <lab...@su...> Subject: gle-4.3.3 in Gentoo Hello *, I've just committed a gle-4.3.3 package to Gentoo. gle-4.3.3.ebuild does not look nice. I had to install files to their proper locations from .../gle-4.3.3_build/ and from .../GLE-4.3.3/src/ (the original sources; some needed files are not present in the build directory) by hand. I had to comment out generation of inittex.ini from TeX/CMakeLists.txt (because it called the old version of gle installed in the system, not the freshly compiled gle), and to generate it by hand. I had to install the gle binary as /usr/bin/gle.bin, and install the shell wrapper /usr/bin/gle: #!/bin/sh export GLE_TOP=/usr/share/gle exec /usr/bin/gle.bin $* because it seems to be no way to run the gle binary without setting GLE_TOP. I installed the gle data files in /usr/share/gle. And, as I said, I had to apply quite a number of patches. And there is no man page :-( But this set of kludges seems to work. I'll sort out the patches and prepare the generally useful (not just for Gentoo) ones in the form of a github PR. Merry Christmas to everybody, Andrey |
From: Vincent L. <lab...@su...> - 2022-12-21 21:02:38
|
Andrey: A lot of questions here related to installation. Some information can be found here on the default locations that cmake uses https://cmake.org/cmake/help/latest/command/install.html the command install(TARGETS gle CONFIGURATIONS Release Debug RUNTIME ) Puts it in the ${CMAKE_INSTALL_PREFIX}/bin folder The command install(FILES ${CMAKE_CURRENT_BINARY_DIR}/glerc CONFIGURATIONS Release Debug DESTINATION . ) Puts glerc in the ${CMAKE_INSTALL_PREFIX} folder So final directory structure looks like this if I set CMAKE_INSTALL_PREFEX = ~/mygle ~/mygle/bin/gle ~/mygle/glerc the goal of the install commands in cmake is to produce the _exect_ folder and file location that would occur if the program where installed using an install script or installer. This is done so cpack can package it up and make installers from it. If CMAKE_INSTALL_PREFIX is not set then it puts it in the default system folder, which for windows would be "c:\Program Files". I typically avoid this and install it to a temporary location first so building is easier and it does not over write my working copy. You may need to set CMAKE_INSTALL_PREFIX=/var/tmp/portage/svi-visualization/gle-4.3.3/image/ on the command line when cmake generates the makefiles. cmake -s src -B mybuild -DCMAKE_INSTALL_PREFIX=/var/tmp/portage/svi-visualization/gle-4.3.3/image/ I think the .so is not in the release distributions - it is really only needed by developers who want to use the gle library in their own code - so no need to install Hope this helps Vince -----Original Message----- From: Andrey G. Grozin <A.G...@in...> Sent: Tuesday, December 20, 2022 4:19 AM To: Vincent LaBella <lab...@su...> Cc: glx...@li...; Christian T. Steigies <ct...@de...> Subject: installation Vincent, Thank you for explanations. Unfortunately, I still have more questions than answers :-( I have to explain briefly how things are done in Gentoo, and what I want to achieve. In Gentoo, installation consists of 2 steps. First, all files (after compilation, linking etc.) are copied to the installation image, which is normally /var/tmp/portage/svi-visualization/gle-4.3.3/image/ During this step, modifications of the live filesystem outside the installation image are forbidden. At the last steps, all files belonging to the old version of the package (if it is installed) are removed from the live filesystem, and the files from the installation image are copied to their final destinations in the live filesystem. The only (!) file which is installed by the cmake build system to the place I expect is qgle. This is because gui/CMakeLists.txt contains install(TARGETS qgle RUNTIME BUNDLE DESTINATION bin ) and I find it at /var/tmp/portage/sci-visualization/gle-4.3.3/image/usr/bin/qgle as expected. All install statements in other CMakeLists.txt contain something like install(... DESTINATION . ) In other words, they are not installed, but continue to live in /var/tmp/portage/sci-visualization/gle-4.3.3/work/gle-4.3.3_build/ Is this intentional? This is not a problem, I can easily install them to the places I need in gle-4.3.3.ebuild Binary programs gle and qgle go to bin/, README.txt and ChangeLog.txt go to share/doc/gle-4.3.3/. This is clear. Should I install gle/liblibgle-graphics.so? Or end users don't need it, the binary program gle/gle is self-contained, and does not need this .so file for running? Where is the man page gle.1? I've found it neither in https://github.com/vlabella/GLE nor in https://github.com/vlabella/gle-manual. In the previous version (4.2.5) there was a man page. Has it disappeared? Where should I install glerc, init.tex, inittex.ini, fonts, and gleinc? In other words, where gle will search for them on an end-user's system? In 4.2.5, the file structure was /usr/share/gle-graphics/4.2.5/ gleinc init.tex inittex.ini gleinc/*.gle fonts/ font.dat *.fmt *.fve What is the corresponding directory for 4.3.3 where gle will search for these files on an end-user's system? Is it /usr/share/gle-4.3.3/, /usr/share/gle/gle/4.3.3/, /usr/share/gle-graphics/4.3.3/, or something else? Andrey |
From: Andrey G. G. <A.G...@in...> - 2022-12-21 16:24:08
|
Hello *, I've just committed a gle-4.3.3 package to Gentoo. gle-4.3.3.ebuild does not look nice. I had to install files to their proper locations from .../gle-4.3.3_build/ and from .../GLE-4.3.3/src/ (the original sources; some needed files are not present in the build directory) by hand. I had to comment out generation of inittex.ini from TeX/CMakeLists.txt (because it called the old version of gle installed in the system, not the freshly compiled gle), and to generate it by hand. I had to install the gle binary as /usr/bin/gle.bin, and install the shell wrapper /usr/bin/gle: #!/bin/sh export GLE_TOP=/usr/share/gle exec /usr/bin/gle.bin $* because it seems to be no way to run the gle binary without setting GLE_TOP. I installed the gle data files in /usr/share/gle. And, as I said, I had to apply quite a number of patches. And there is no man page :-( But this set of kludges seems to work. I'll sort out the patches and prepare the generally useful (not just for Gentoo) ones in the form of a github PR. Merry Christmas to everybody, Andrey |
From: Andrey G. G. <A.G...@in...> - 2022-12-21 06:09:52
|
On Wed, 21 Dec 2022, Andrey G. Grozin wrote: > In the previous version, the result is > > grozin@bilbo ~ $ gle -info > GLE version: 4.2.5 > Build date: May 26 2021 10:19:17 > GLE_TOP: /usr/share/gle-graphics/4.2.5 > GLE_BIN: /usr/bin > GhostScript: gs > Bitmap import: JPEG, PNG, TIFF, GIF > Cairo rendering support: Yes > Poppler PDF support: Yes > > and indeed, gle-related files are installed in /usr/share/gle-graphics/4.2.5 I see from where this directory has appeared. In configure.ac there were the lines GLE_INSTALL_DATA=/usr/share/$PACKAGE_TARNAME/$GLE_VERSION .... GLE_INSTALL_DATA=$prefix/share/$PACKAGE_TARNAME/$GLE_VERSION In 4.3.3, the word "share" appears nowhere in the new cmake-based build machinery, and it is impossible to obtain a reasonable initial value for GLE_TOP_DIR (which must contain /usr/share/). Andrey |
From: Andrey G. G. <A.G...@in...> - 2022-12-21 05:58:28
|
On Tue, 20 Dec 2022, Andrey G. Grozin wrote: > Where is the man page gle.1? I've found it neither in > https://github.com/vlabella/GLE nor in > https://github.com/vlabella/gle-manual. In the previous version (4.2.5) there > was a man page. Has it disappeared? Yes it has :-( In gle-graphics-4.2.5f there is src/doc/gle.1.in, in gle-4.3.3 it is missing. Is it possible to get the man page back? Andrey |
From: Andrey G. G. <A.G...@in...> - 2022-12-21 05:47:47
|
On Tue, 20 Dec 2022, Andrey G. Grozin wrote: > Where should I install glerc, init.tex, inittex.ini, fonts, and gleinc? In > other words, where gle will search for them on an end-user's system? In > 4.2.5, the file structure was > > /usr/share/gle-graphics/4.2.5/ > gleinc > init.tex > inittex.ini > gleinc/*.gle > fonts/ > font.dat > *.fmt > *.fve > > What is the corresponding directory for 4.3.3 where gle will search for these > files on an end-user's system? Is it /usr/share/gle-4.3.3/, > /usr/share/gle/gle/4.3.3/, /usr/share/gle-graphics/4.3.3/, or something else? After looking into the sources, things are becoming more clear (but not completely). glerc, init.tex, inittex.ini, fonts, and gleinc should be installed in GLE_TOP_DIR. If the user has defined the environment variable GLE_TOP, it is taken from this variable. Otherwise, config.cpp tries to initialize GLE_TOP_DIR using some (not quite understandable) logic. It starts from the path to the program (/usr/bin/gle) and makes some manipulations with this path. In the previous version, the result is grozin@bilbo ~ $ gle -info GLE version: 4.2.5 Build date: May 26 2021 10:19:17 GLE_TOP: /usr/share/gle-graphics/4.2.5 GLE_BIN: /usr/bin GhostScript: gs Bitmap import: JPEG, PNG, TIFF, GIF Cairo rendering support: Yes Poppler PDF support: Yes and indeed, gle-related files are installed in /usr/share/gle-graphics/4.2.5 Running this with a freshly compiled (uninstalled) gle, I predictably see bilbo gle # ./gle -info Error: GLE is unable to locate its configuration file. GLE searched these locations: '/var/tmp/portage/sci-visualization/gle-4.3.3/work/gle-4.3.3_build/glerc' Please set GLE_TOP to the correct location. But config.cpp in principle cannot set GLE_TOP_DIR to something reasonable like /usr/share/gle or whatever, because the word "share" is absent in it: grozin@bilbo ~/gle/GLE-4.3.3 $ find -name '*.cpp' | xargs fgrep share ./src/gui/serverthread.cpp: // Use a locker to get access to shared variables, How is config.cpp supposed to assign something reasonable to GLE_TOP_DIR when GLE_TOP is not set? Or the only way to distribute gle-4.3.3 to end users (on linux at least) is to write a shell wrapper around it which sets GLE_TOP? Andrey |
From: Andrey G. G. <A.G...@in...> - 2022-12-20 09:19:23
|
Vincent, Thank you for explanations. Unfortunately, I still have more questions than answers :-( I have to explain briefly how things are done in Gentoo, and what I want to achieve. In Gentoo, installation consists of 2 steps. First, all files (after compilation, linking etc.) are copied to the installation image, which is normally /var/tmp/portage/svi-visualization/gle-4.3.3/image/ During this step, modifications of the live filesystem outside the installation image are forbidden. At the last steps, all files belonging to the old version of the package (if it is installed) are removed from the live filesystem, and the files from the installation image are copied to their final destinations in the live filesystem. The only (!) file which is installed by the cmake build system to the place I expect is qgle. This is because gui/CMakeLists.txt contains install(TARGETS qgle RUNTIME BUNDLE DESTINATION bin ) and I find it at /var/tmp/portage/sci-visualization/gle-4.3.3/image/usr/bin/qgle as expected. All install statements in other CMakeLists.txt contain something like install(... DESTINATION . ) In other words, they are not installed, but continue to live in /var/tmp/portage/sci-visualization/gle-4.3.3/work/gle-4.3.3_build/ Is this intentional? This is not a problem, I can easily install them to the places I need in gle-4.3.3.ebuild Binary programs gle and qgle go to bin/, README.txt and ChangeLog.txt go to share/doc/gle-4.3.3/. This is clear. Should I install gle/liblibgle-graphics.so? Or end users don't need it, the binary program gle/gle is self-contained, and does not need this .so file for running? Where is the man page gle.1? I've found it neither in https://github.com/vlabella/GLE nor in https://github.com/vlabella/gle-manual. In the previous version (4.2.5) there was a man page. Has it disappeared? Where should I install glerc, init.tex, inittex.ini, fonts, and gleinc? In other words, where gle will search for them on an end-user's system? In 4.2.5, the file structure was /usr/share/gle-graphics/4.2.5/ gleinc init.tex inittex.ini gleinc/*.gle fonts/ font.dat *.fmt *.fve What is the corresponding directory for 4.3.3 where gle will search for these files on an end-user's system? Is it /usr/share/gle-4.3.3/, /usr/share/gle/gle/4.3.3/, /usr/share/gle-graphics/4.3.3/, or something else? Andrey |
From: Vincent L. <lab...@su...> - 2022-12-19 13:41:57
|
Andrey: The init.tex file gets generated during the cmake install phase. There are 4 phases of building with cmake 1. generating makefiles cmake -s src -B mybuild -D... 2. building cd mybuild ; make 3. installation cmake -P mybuild/cmake_install.cmake 4. packaging (optional) cd mybuild ; -G "ZIP;7Z" -C "Release" -B "~/my_install_folder" you can control the install location during phase 1 by setting -DCMAKE_INSTALL_PREFIX="~/my_install_folder" otherwise it puts in in the system default location I tend to use a custom install location - then package it - then install it from the package. To make sure it works Hope this helps Vince -----Original Message----- From: Andrey G. Grozin <A.G...@in...> Sent: Monday, December 19, 2022 12:38 AM To: glx...@li... Cc: Christian T. Steigies <ct...@de...>; Vincent LaBella <lab...@su...> Subject: Re: [GLE-devel] compiling gle-4.3.3: next step On Mon, 19 Dec 2022, Andrey G. Grozin wrote: > Where this inittex.ini generation defined? Aha, I see: TeX/CMakeLists.txt Will investigate Andrey |
From: Andrey G. G. <A.G...@in...> - 2022-12-19 05:38:37
|
On Mon, 19 Dec 2022, Andrey G. Grozin wrote: > Where this inittex.ini generation defined? Aha, I see: TeX/CMakeLists.txt Will investigate Andrey |
From: Andrey G. G. <A.G...@in...> - 2022-12-19 04:10:13
|
On Sun, 18 Dec 2022, Christian T. Steigies wrote: > I think the order in which the libraries are linked is the problem. > Please see the attached patch which helps me build qgle on Debian. Yes, you are right. libgle-graphics_s definitely should be before ${ZLIB_LIBRARIES} not after. Now my packaging work seems mostly done. But one problem remains. It is at the install time. I see >>> Install sci-visualization/gle-4.3.3 into /var/tmp/portage/sci-visualization/gle-4.3.3/image * Source directory (CMAKE_USE_DIR): "/var/tmp/portage/sci-visualization/gle-4.3.3/work/GLE-4.3.3/src" * Build directory (BUILD_DIR): "/var/tmp/portage/sci-visualization/gle-4.3.3/work/gle-4.3.3_build" ninja -v -j6 -l0 install [0/1] cd /var/tmp/portage/sci-visualization/gle-4.3.3/work/gle-4.3.3_build && /usr/bin/cmake -P cmake_install.cmake -- Install configuration: "Gentoo" -- Installing: /var/tmp/portage/sci-visualization/gle-4.3.3/image/usr/bin/qgle * ACCESS DENIED: unlink: /usr/share/gle-graphics/4.2.5/inittex.ini GLE 4.2.5[init.tex]-C-R- If GLE says 'Saving definitions', then compilation was successful. >> init.tex (692) |end text| Saving definitions * ACCESS DENIED: fopen_wr: /usr/share/gle-graphics/4.2.5/inittex.ini Could not create inittex.ini file Well, these ACCESS DENIED messages are from the Gentoo sandbox, this detail is Gentoo specific, sorry. But why the installation process tries to remove /usr/share/gle-graphics/4.2.5/inittex.ini from the live filesystem, not from the install image? It belongs to the previously installed gle-4.2.5. Why the installation process calls the previously installed old gle?? GLE 4.2.5[init.tex]-C-R- And this old gle (4.2.5) tries to write to /usr/share/gle-graphics/4.2.5/inittex.ini, a file in the live filesystem, and the sandbox naturally forbids it. Shouldn't the installation process call the freshly compiled gle instead? And generate inittex.ini in the install image? Where this inittex.ini generation defined? Hope for some further help, Andrey |