Yes, I did check spelling.
I think I may have found the problem. GraphicsMagick is different from the other supportApp directories because it has a top-level directory with uses RULES_DIRS and then the actual src directories under that which use RULES.
It looks like directories with RULES_DIRS are not reading the CONFIG_SITE.* files at that level, but rather only once they have descended into the src directories. I can see that by putting warnings messages in the CONFIG_SITE.* files. I should be able to make it work by moving the logic into each src directory Makefile.
Mark
________________________________
From: [email protected] [[email protected]] on behalf of Ralph Lange [[email protected]]
Sent: Sunday, June 04, 2017 1:58 PM
To: EPICS Core Talk
Subject: Re: Build problem
Weird. Did you quadruple-check the spelling of things?
~Ralph
On Sun, Jun 4, 2017 at 8:25 PM, Mark Rivers <[email protected]<mailto:[email protected]>> wrote:
I just found that I am having another problem which I am quite sure is related.
I want to build GraphicsMagick on all architectures except vxWorks. I thus have this line in my CONFIG_SITE.local.$(EPICS_HOST_ARCH).$(T_A) i.e. CONFIG_SITE.local.linux-x86.vxWorks-ppc32 file:
WITH_GRAPHICSMAGICK = NO
This should prevent GraphicsMagick from being built on vxWorks. However, as with GRAPHICSMAGICK_EXTERNAL it seems to be ignored.
However if I add this line to that file
WITH_TIFF = NO
this works correctly, it prevents building ADSupport/supportApp/tiffSrc on vxWorks. So again the problem seems somehow specific to GraphicsMagick.
Thanks,
Mark
From: Mark Rivers
Sent: Sunday, June 04, 2017 12:57 PM
To: [email protected]<mailto:[email protected]>; EPICS Core Talk
Subject: Build problem
I'm having a problem building GraphicsMagick in areaDetector/ADSupport and I'm stumped.
Here's the problem.
The top-level areaDetector/configure/CONFIG_SITE includes these lines:
#######################
-include $(AREA_DETECTOR)/configure/CONFIG_SITE.local
-include $(AREA_DETECTOR)/configure/CONFIG_SITE.local.$(OS_CLASS)
-include $(AREA_DETECTOR)/configure/CONFIG_SITE.local.$(EPICS_HOST_ARCH)
-include $(AREA_DETECTOR)/configure/CONFIG_SITE.local.$(EPICS_HOST_ARCH).$(T_A)
#######################
So it reads 4 CONFIG_SITE.local.* files if they exist.
ADSupport/configure/CONFIG_SITE includes these lines:
#######################
# Get settings from AREA_DETECTOR, so we only have to configure once for all detectors if we want to
-include $(AREA_DETECTOR)/configure/CONFIG_SITE
-include $(AREA_DETECTOR)/configure/CONFIG_SITE.$(EPICS_HOST_ARCH)
-include $(AREA_DETECTOR)/configure/CONFIG_SITE.$(EPICS_HOST_ARCH).Common
ifdef T_A
-include $(AREA_DETECTOR)/configure/CONFIG_SITE.Common.$(T_A)
-include $(AREA_DETECTOR)/configure/CONFIG_SITE.$(EPICS_HOST_ARCH).$(T_A)
endif
#######################
So it reads a number of files from$(AREA_DETECTOR)/configure if they exist. The only one that actually exists is CONFIG_SITE, whose contents I have shown above.
CONFIG_SITE.local includes these lines:
#######################
...
# GraphicsMagick is required for NDFileMagick and the URL driver.
WITH_GRAPHICSMAGICK = YES
GRAPHICSMAGICK_EXTERNAL = YES
# GraphicsMagick defines many global symbols, and one of these (SetImage) conflicts with a symbol
# in the Andor vendor library. GraphickMagick provides a solution by allowing all external library
# symbols to be prefixed with "Gm". Enable using this by default. However, if a system library
# is used it may not be built with this option so this line should be commented out.
GRAPHICSMAGICK_PREFIX_SYMBOLS = YES
#GRAPHICSMAGICK_INCLUDE =
#GRAPHICSMAGICK_LIB =
...
# TIFF is required for the NDFileTIFF plugin.
WITH_TIFF = YES
TIFF_EXTERNAL = YES
#TIFF_INCLUDE =
#TIFF_LIB =
# XML2 is required for ADCore so there is no WITH_XML2.
XML2_EXTERNAL = YES
#XML2_INCLUDE =
#XML2_LIB =
#######################
Among other things it defines WITH_GRAPHICSMAGICK=YES, GRAPHICSMAGICK_EXTERNAL=YES, WITH_TIFF=YES, TIFF_EXTERNAL=YES, XML2_EXTERNAL=YES.
My CONFIG_SITE.local.Linux includes these lines:
#######################
GRAPHICSMAGICK_EXTERNAL = NO
TIFF_EXTERNAL = NO
XML2_EXTERNAL = NO
#######################
So it overrides the CONFIG_SITE.local to set xxx_EXTERNAL for each of these libraries to NO rather than YES.
The Makefiles in ADSupport look at the xxx_EXTERNAL flag to decide whether or not to actually build that library. If it is not NO then it does not build the library.
CONFIG_SITE.local.WIN32 does the same thing for Windows, and again it defines all of the xxx_EXTERNAL flags to NO.
This whole mechanism is generally working fine. If, for example I comment out the TIFF_EXTERNAL=NO or XML2_EXTERNAL=NO lines in CONFIG_SITE.local.Linux then ADSupport will not build those libraries when I run make in those directories.
The exception to the correct operation is GRAPHICSMAGICK_EXTERNAL=NO. This flag is correctly obeyed if it set in CONFIG_SITE.local or CONFIG_SITE.local.$(EPICS_HOST_ARCH), e.g. CONFIG_SITE.local.linux-x86_64. However, when this flag is set in CONFIG_SITE.local.Linux then it is being ignored. I am completely baffled by this, since it seems to be equivalent to each of the other flags like XML2_EXTERNAL=NO which are being picked up correctly from CONFIG_SITE.local.Linux.
I have the same problem on Windows. XM2_EXTERNAL=NO is picked up correctly from CONFIG_SITE.local.WIN32, but GRAPHICSMAGICK_EXTERNAL=NO seems to be ignored in this file. But it is working correctly if it is defined in CONFIG_SITE.local or CONFIG_SITE.local.$(EPICS_HOST_ARCH), e.g. CONFIG_SITE.local.windows-x64-static.
This is the ADSupport/supportApp/GraphicsMagick/Makefile
#######################
TOP = ../..
include $(TOP)/configure/CONFIG
#---------------------------------------
# ADD MACRO DEFINITIONS AFTER THIS LINE
#=======================================
ifeq ($(WITH_GRAPHICSMAGICK),YES)
ifeq ($(GRAPHICSMAGICK_EXTERNAL),NO)
DIRS += filters
filters_DEPEND_DIRS += magick ttf
DIRS += wmf
DIRS += webp
DIRS += png
png_DEPEND_DIRS += bzlib
DIRS += jp2
DIRS += jbig
DIRS += coders
coders_DEPEND_DIRS += bzlib jbig jp2 magick png ttf webp wmf
DIRS += lcms
DIRS += bzlib
DIRS += ttf
DIRS += magick
magick_DEPEND_DIRS += bzlib lcms ttf
DIRS += Magick++
Magick++_DEPEND_DIRS += magick coders
endif # ($(GRAPHICSMAGICK_EXTERNAL),NO)
endif # ($(WITH_GRAPHICSMAGICK),YES)
include $(TOP)/configure/RULES_DIRS
#----------------------------------------
# ADD RULES AFTER THIS LINE
#######################
It looks just like the tiffSrc/Makefile
#######################
TOP=../..
include $(TOP)/configure/CONFIG
#----------------------------------------
# ADD MACRO DEFINITIONS AFTER THIS LINE
#=============================
ifeq ($(WITH_TIFF),YES)
ifeq ($(TIFF_EXTERNAL),NO)
INC += tiff.h
INC += tiffio.h
INC += tiffvers.h
INC += tiffconf.h
...
tiff_SRCS += tif_write.c
tiff_SRCS += tif_zip.c
tiff_SRCS_Linux += tif_unix.c
tiff_SRCS_WIN32 += tif_win32.c
tiff_SRCS_vxWorks += tif_vxWorks.c
endif # ($(TIFF_EXTERNAL),NO)
endif # ($(WITH_TIFF),YES)
include $(TOP)/configure/RULES
#----------------------------------------
# ADD RULES AFTER THIS LINE
#######################
But tiffSrc is behaving like it should and GraphicsMagick is not.
All of the areaDetector/configure/CONFIG* files I am using are identical to the configure/EXAMPLE_CONFIG* on the master branch on Github except for CONFIG_SITE.local.Linux where I have uncommented all of the xxx_EXTERNAL=NO lines. ADSupport is identical to the master branch on Github.
I have search the entire areaDetector tree (actually the entire synApps tree as well) to see if GRAPHICSMAGICK_EXTERNAL might be defined somewhere else, but it is not.
Any ideas on how to track down this problem would be most appreciated!
Thanks,
Mark
- Replies:
- RE: Build problem Mark Rivers
- References:
- Build problem Mark Rivers
- RE: Build problem Mark Rivers
- Re: Build problem Ralph Lange
- Navigate by Date:
- Prev:
Re: Build problem Ralph Lange
- Next:
Re: terminate called after throwing an instance of 'epicsMutex::invalidMutex' Marty Kraimer
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
<2017>
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Build problem Ralph Lange
- Next:
RE: Build problem Mark Rivers
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
<2017>
2018
2019
2020
2021
2022
2023
2024
|