Good morning, Salva and Anton. Next week I will try once again with xenial, after having installed glib-2.0 . I remember that build operation is aimed to ascertain whether the behavior of of the present AppImage version of smtk2ssrf is like the behavior of the corresponding regular application. As already explained in my previous messages the AppImage produces sometimes different output .xml files from the same input .slg file.
I am now beginning to suspect that this surprising behavior might be the result of some instability in libmdb when the Microsoft data base is being read. If this is actually the case also the "regular" application would be affected by the same instability of the AppImage. As far as the behavior of the build script on Fedora I am probably missing something. I have never used cmake and my competence about it is close to zero. My limited knowledge about the C preprocessor is that a macro is expanded by the preprocessor before the compilation process is started. In the object module the macro simply does not exist; it has been expanded by text substitution and the resulting C source code has been processed by the compiler. It is therefore normal to have the same macro definition in the header of different source files or even a different definition in different files ( although I would not recommend to do that ). As far as the linking of the object modules is concerned this should not be relevant. I remember of having read that it is also possible to have multiple definitions of a macro inside a single source file, under certain conditions, but I never dared to do so and I have never found any reason for doing so. If I need more than one definition for a macro I think that the best solution is to use different names for different macros. In any case the definition "#define MAX(a, b) (((a) > (b)) ? (a) : (b))" is standard and is used in a huge number of C source files; therefore I do not understand why should cmake complain about it, even if the macro definition is in the header of more than one source file. Anton is almost certainly right when he says that the issue is related to need to extend the cmake script so that it is also able to produce a subsurface Windows executable ... the problem is that such issue only affects the Fedora version of cmake, since the Ubuntu version seems not to be affected. Best regards. Alessandro On Thu, Feb 23, 2017 at 11:01 PM, Salvador Cuñat <[email protected]> wrote: > Good night Alessandro and Anton. > > On Thu, Feb 23, 2017 at 10:59:59PM +0100, Anton Lundin wrote: > > On 23 February, 2017 - Alessandro Volpi wrote: > > > > > > > > In file included from /home/ale/src/subsurface/smtk- > import/smartrak.c:32:0: > > > ---- > > > /home/ale/src/subsurface/./core/dive.h:20:0: warning: "MAX" redefined > > > #define MAX(x, y) ({ \ > > > > > > In file included from /usr/lib64/glib-2.0/include/glibconfig.h:9:0, > > > from /usr/include/glib-2.0/glib/gtypes.h:32, > > > from /usr/include/glib-2.0/glib/galloca.h:32, > > > from /usr/include/glib-2.0/glib.h:30, > > > from /usr/include/mdbtools.h:33, > > > from /home/ale/src/subsurface/smtk- > import/smartrak.c:28: > > > /usr/include/glib-2.0/glib/gmacros.h:288:0: note: this is the > location of > > > the previous definition > > > #define MAX(a, b) (((a) > (b)) ? (a) : (b)) > > > ---- > > > ---- > > > "CMakeFiles/smtk2ssrf.dir/build.make:247: recipe for target > 'smtk2ssrf' > > > failed make[2]: *** [smtk2ssrf] Error 1" > > > ---- > That are just warnings, what is really failing is: > > [ 88%] Linking CXX executable smtk2ssrf > c++: error: missing argument to ‘-L’ > CMakeFiles/smtk2ssrf.dir/build.make:247: recipe for target 'smtk2ssrf' > failed > make[2]: *** [smtk2ssrf] Error 1 > CMakeFiles/Makefile2:336: recipe for target > 'CMakeFiles/smtk2ssrf.dir/all' failed > > I've only seen this on fedora. Never on Debian or centOS. > It's not smtk2ssrf related. > Could it be triggered by the cmake version included in fedora ? > > The problem in Xenial is because of glib-2.0 not installed. > In Debian the package is libglib2.0-dev, in Ubuntu is probably the > same package name. > > > > BTW I do not understand why the usual MAX(x,y) macro should be > redefined ... > > > > There's no such thing as the usual MAX(x,y) macro. > > > > On my laptop I find that exact macro in 8 different header files in > > /usr/include , from about as many different libraries, so its just a > > matter of time before this kind of things happens. > > > > And another angle of it, those where introduced in 475e058d, because > > windows doesn't have those macros. > > > > I'd suggest we throw a #undef before those macros in core/dive.h to get > > rid of this sort of nonsens issues, our do as we did before 475e058d, > > and use the ones from sys/param.h on non windows platforms, and ifdef > > those macros to windows. > > > I don't think this is really needed, the warnings only appear because > of glib-2.0 which is only needed in smtk-import, whose building is > dissabled by default and has seen little use or even testing until now > (thanks Alessandro for all your testing here). > > Regards. > > Salva >
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
