From: phil r. <phi...@ya...> - 2014-02-25 12:29:22
|
Hi All I'm resorting my various libraries into a single directory, mostly because of the way visual studio now allows users to add directories, but also partly because of the discussion we had about depreciating the LIB_TAG option. However, when I do so, and when I specify this directory using -DCMAKE_LIBRARY_PATH the Agg library is not found. Checking the findAGG module it seems rather complex by comparison to e.g. findFreetype. It seems that AGG is not being found because on windows PKG_CONFIG_EXECUTABLE is false, so the variable _AGGLinkFlags isn't set and findAGG therefore doesn't ever look for the library. Commenting out the if(_AGGLinkFlags) line allows AGG to be found correctly. Is there any need for all the pkgconfig stuff? Phil |
From: Alan W. I. <ir...@be...> - 2014-02-25 17:47:44
|
On 2014-02-25 04:29-0800 phil rosenberg wrote: > I'm resorting my various libraries into a single directory, mostly because of the way visual studio now allows users to add directories, but also partly because of the discussion we had about depreciating the LIB_TAG option. However, when I do so, and when I specify this directory using -DCMAKE_LIBRARY_PATH the Agg library is not found. Checking the findAGG module it seems rather complex by comparison to e.g. findFreetype. It seems that AGG is not being found because on windows PKG_CONFIG_EXECUTABLE is false, so the variable _AGGLinkFlags isn't set and findAGG therefore doesn't ever look for the library. Commenting out the if(_AGGLinkFlags) line allows AGG to be found correctly. > Is there any need for all the pkgconfig stuff? I agree there is an issue there that I would be willing to fix. However, is there a need for any agg fixups at all when you are about to deliver a patch (discussed prior to the last release and put off until now) that would remove the agg variant of the wxwidgets and thus all dependence of PLplot on agg? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Werner S. <wer...@mi...> - 2014-02-25 20:36:07
|
Hi Phil, this was way back, when we switched to the cmake build system and my knowledge about cmake was not that good (is not that good either, since the peak was 3 years ago ;). Anyway pkg_config is not needed but useful if it's always there. I think gtk libraries are found that way as well as wxwidgets libraries on Linux/Mac OS X using wxconfig. Especially for wxWidgets it makes the cmake module much easier (the Windows part is a major PITA). So, I think the FindAGG module can be changed not using pkg-config but you should check if it still works for at least Linux. You could try to find another FindAGG module on the net. There might be other versions which are better suited for your/our needs. HTH, Werner > phil rosenberg <mailto:phi...@ya...> > 25 February 2014 13:29 > Hi All > I'm resorting my various libraries into a single directory, mostly > because of the way visual studio now allows users to add directories, > but also partly because of the discussion we had about depreciating > the LIB_TAG option. However, when I do so, and when I specify this > directory using -DCMAKE_LIBRARY_PATH the Agg library is not found. > Checking the findAGG module it seems rather complex by comparison to > e.g. findFreetype. It seems that AGG is not being found because on > windows PKG_CONFIG_EXECUTABLE is false, so the variable _AGGLinkFlags > isn't set and findAGG therefore doesn't ever look for the library. > Commenting out the if(_AGGLinkFlags) line allows AGG to be found > correctly. > > Is there any need for all the pkgconfig stuff? > > Phil > ------------------------------------------------------------------------------ > Flow-based real-time traffic analytics software. Cisco certified tool. > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > Customize your own dashboards, set traffic alerts and generate reports. > Network behavioral analysis & security monitoring. All-in-one tool. > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Alan W. I. <ir...@be...> - 2014-02-26 18:02:12
|
Hi Phil: I hope you don't mind that I have redirected this thread back to the list. On 2014-02-26 04:11-0800 phil rosenberg wrote: > Hi Alan, that's good regarding the shapelib. No don't worry about the AGG module. OK. Thanks for that response to my question. > Regarding the Freetype module - The CMake provided version unfortunately doesn't work with freetype 2.5, which is what I am using at the moment. But it should work with 2.4 so I can downgrade or hack their version. I will report it to them as a bug, then it's their problem. I guess we can simply remove the module from plplot. Yes, that removal has already been done as part of my commit which makes cmake automatically fall back to the CMake version of that find module. Are PATHS values like [HKEY_CURRENT_USER\\SOFTWARE\\gtkmm\\2.4;Path] [HKEY_LOCAL_MACHINE\\SOFTWARE\\gtkmm\\2.4;Path] in the CMake version the issue? This general form of PATHS value is not well documented by CMake, but it is ubiquitous in their official find modules. From the few sparse references to registry keys within the documentation, I assume this has something to do with the registry, and you likely have to add the equivalent for 2.5 to get everything working for the case when you are relying on the registry. If so, that is definitely worth a bug report to KitWare. N.B. There should be no need to downgrade. You should also have a pretty straightforward workaround available for that bug which is to use the appropriate environment variables (such as CMAKE_LIBRARY_PATH) to guide CMake to find wherever you have installed freetype 2.5. See the documentation of the CMake find_path command to find all the relevant environment variables that will affect the find_path searches in the CMake version of FindFreetype.cmake. By the way, Wine does have a registry to provide the equivalent registry functionality that Microsoft Windows has, and it may be a step above what is possible with the Microsoft Windows registry since it is an ascii file that can be edited rather than a binary one. In any case I have heard bad things about the Microsoft Windows registry so when I install packages for Wine I usually use idiosyncratic install prefixes and attempt to avoid the registry as much as possible just on general principles. Since bash.exe is available to me from MSYS and pkg-config.exe available to me from epa_build, I normally rely on ordinary bash.exe environment variables (along with the CMake ability to execute pkg-config) to provide the guidance that CMake needs to find software. See cmake/epa_build/README. One bash.exe "source" command conveniently sets up all required environment variables using the appropriate file in cmake/epa_build/setup. Those files represent my own Linux and Wine platform install idiosyncrasies so are not directly useful to anyone else, but they do serve as a template for other epa_build users. And once Arjen has complete epa_build success with plplot_lite on MinGW/MSYS/Microsoft Windows following what I have done on MinGW/MSYS/Wine, I will strongly encourage him to commit his own setup file(s) to serve as a template for the MinGW/MSYS/Microsoft Windows platform. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |