Hi Laurent
Just a not about naming - I too expected a d suffix on the library
name to represent debug when I first started using plplot. There used
to be a cmake option to add a suffix to the name, but it is no longer
listed on https://sourceforge.net/p/plplot/wiki/CMake_options_for_PLplot/
- Alan do you know if it is still implemented and if so what it is?
There used to be a d suffix added to represent the fact that the
library was built with double precision floating point variables, but
I don't think this is the case any more.
I used to add the d suffix for debug builds, but in the end I stopped.
I came across too many libraries that didn't do it. I have a feeling
it is an inherently windows style thing (you only need debug libraries
if they are static rather than shared and Linux users never seem to
build static libraries), so many Linux-centric open source projects
don't do it. Maybe I'm wrong in saying this, it's only my thoughts.
Anyway, my solution was to install my debug libraries in a folder
specific to debug libraries. Almost every library has a way to specify
the install prefix. With plplot you can do this with the
-DCMAKE_LIBRARY_PATH or -DCMAKE_INSTALL_PREFIX
Whether you go for a prefix option or if a suffix is possible you will
need to run cmake twice, once for release and once for debug and once
for release by setting the -DCMAKE_CONFIGURATION_TYPES options to
"Debug" or "Release".
Phil
On Tue, 25 Sep 2018 at 22:08, Alan W. Irwin <alan.w.irwin1...@gmail.com> wrote:
>
> On 2018-09-25 22:05+0200 Laurent Berger wrote:
>
> > Hi,
> >
> > I want to use plplot in my own project using cmake and I miss something. my
> > cmakelists.txt is see below and it works. But in include_directories cmake
> > command I must write :
> >
> > include_directories(${plplot_DIR}/../../../include) and it is really weird.
> > what's variable name for include ?
>
> [...]
>
> > CMakeLists.txt
> >
> [...]
> > find_package(plplot)
> [...]
> > ADD_EXECUTABLE (${NomProjet} ${Projet_SRCS} )
> [...]
> > if (plplot_FOUND)
> >
> > include_directories(${plplot_DIR}/../../../include)
> > target_link_libraries( ${NomProjet} PUBLIC PLPLOT::plplotwxwidgets)
> > else (plplot_FOUND)
> > message( " PROBLEME" )
> > endif(plplot_FOUND)
>
> Hi Laurent:
>
> I have reviewed the redacted version above, and all seems well. For
> example, our installed examples are similarly built against the
> installed version of PLplot, and what you have implemented above
> follows that same method. For example, you can see
> "find_package(plplot)" (in the non-CORE_BUILD part of
> examples/CMakeLists.txt), and a combination of add_executable,
> include_directories (which refers to the installed location of PLplot
> for the non-CORE_BUILD case just like you apparently have
> implemented), and target_link_libraries in examples/c/CMakeLists.txt.
>
> However, you were right to question that include_directories command
> which is necessary now, but should not be necessary in future once I
> set up the export of PLplot to handle compile options properly. But
> that implementation is a little tricky so although it is on my ToDo
> list now, I am going to put it off until after the 5.14.0 release that
> is coming soon.
>
> Alan
> __________________________
> Alan W. Irwin
>
> 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
> __________________________
>
>
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
