Experimental Physics and
Industrial Control System

Mark Rivers <[email protected]> · Mon, 18 May 2015 17:55:56 +0000

Hi Ben,

> In particular, $(TOP)/../configure/ could theoretically collide with some other module's configure directory.

Yes, theoretically.  But the only files we look for there are EPICS_BASE.$(EPICS_HOST_ARCH) and SUPPORT.$(EPICS_HOST_ARCH) which are names we made up for synApps.  So a collision is unlikely.

> The tool then generates the configure RELEASE files according to the application's specification
> about which versions of which modules it depends on.

Does it handle Linux and Windows builds in the same file tree?  If so, how does it do it?

> > -    Deleted this file.  Using this mechanism requires 4 separate
>> RELEASE.$(EPICS_HOST_ARCH) files if one is building for Windows
>> 32/64, static/dynamic.  The -include is a simpler way to do this.
>> This is obviously your call on how you would like to do it.

> Similar considerations apply here as for the previous point.

I would really like to get rid of this file, even if you don't put the -include in configure/RELEASE.  I always get bit by this, because by adding the -include to configure/RELEASE it works on windows-x64, but not in win32-x86, because this file takes precedence and it does not automatically update.

Thanks,
Mark

-----Original Message-----
From: Benjamin Franksen [mailto:[email protected]] 
Sent: Monday, May 18, 2015 5:58 AM
To: Mark Rivers
Cc: '[email protected]'
Subject: Re: Problem building seq-2-2-1 on Windows

Hi Mark

sorry again for the delay. As promised here are some comments/questions.

On Thursday 30 April 2015 17:47:43 Mark Rivers wrote:
> I have made the changes to seq-2-2-2 to get it to build on win32-x86,
> windows-x64, and cygwin-x86.  These are all built dynamically, i.e.
> creating DLLs.  seq-2-2-2 already worked OK for win32-x86-static and
> windows-x64-static, i.e. static builds.
>
> I am running EPICS base 3.14.12.5 with the one patch available at this
> time.
>
> I have attached the patch file.
>
> This is an explanation of each of the changes in the patch, in order
> in the patch file.
>
> configure/RELEASE
>
> -    Different version of EPICS_BASE.  Obviously this is
> site-specific.
>
> -    Added this line
>      -include $(TOP)/../configure/EPICS_BASE.$(EPICS_HOST_ARCH)
>      That line is very helpful when building synApps, since it allows
> a top-level configure/EPICS_BASE.$(EPICS_HOST_ARCH) define a
> different path to EPICS base depending on the architecture. Useful
> when building Windows and Linux in the same tree.

I would like to hear more opinions about this point before applying this
change to the sequencer.

It seems to me that everyone is using their own self-written meta build
system (for building sets of interdependent modules, sometimes including
base). Supporting the one that is used in synApps in the way you propose
makes certain assumptions about where in the file system the sequencer
is installed relative to other modules. In particular,
$(TOP)/../configure/ could theoretically collide with some other
module's configure directory.

Just as a data point: about a year ago we started creating our own meta
build system which is vastly more flexible and reliable than what
SynApps offers: we keep the dependency information in a database
(actually a single JSON file) together with information about how to
assemble the source tree given module name and version (usually by
checking it out from our local Darcs repos). The tool then generates the
configure RELEASE files according to the application's specification
about which versions of which modules it depends on. This lets us much
more easily upgrade modules (including base) which are deep down in the
dependency graph without having to fear that we accidentally forget to
rebuild something and thus risk inconsistencies. It also frees us from
manually figuring out the correct order of building the modules and
allows us to safely share builds if (transitive) dependencies coincide.

> configure/RELEASE.win32-x86
>
> -    Deleted this file.  Using this mechanism requires 4 separate
> RELEASE.$(EPICS_HOST_ARCH) files if one is building for Windows
> 32/64, static/dynamic.  The -include is a simpler way to do this.
> This is obviously your call on how you would like to do it.

Similar considerations apply here as for the previous point.

> examples/demo/Makefile
>
> -    This needed to be changed to build on cygwin-x86.  All symbols
> that are imported because of a dbd file (i.e, function(),
> registrar(), etc.) must be in a library, they cannot be built
> directly into a main program.  Andrew Johnson can explain this
> further if you have questions.
>
> src/seq/Makefile
> src/seq_main.c
> src/seq_prim_types.c (new file)
> src/seq_prim_types.h
> src/snc/var_types.c

Andrew, if you are reading this, I would be very interested to hear
more. Besides, I may have misunderstood this but didn't you write that
EPICS will stop supporting cygwin anyway?

Anyway, it seems harmless to incorporate this change so I'll accept this
patch.

> -    The way that prim_types was being handled does not work on
> win32-x86, windows-x64, or cygwin-x86.  Following Andrew Johnson's
> suggestion I left only the structure definitions in seq_prim_types.h
> (with epicsShareExtern) and moved the value assignments into the new
> seq_prim_types.c file.  This works fine, and also cleans up
> seq_main.c and var_types.c.

I have picked up this pattern from EPICS base sources where it is used
in several places and is documented in shareLib.h. I don't understand
why it works in base but not in the sequencer.

> src/snc/types.h
>
> -    Include stdlib.h, otherwise calloc was not defined.

Ok, accepted.

> test/validate/Makefile
>
> -    Put subThreadSleep.c into a new library.  Same explanation as
> examples/demo/Makefile as above.  Would not build on cygwin-x86.

Accepted (but with the same question attached: what about this peculiar
cygwin behaviour?).

> With these changes seq builds on all 5 architectures I was working on.
>  It also appears to function correctly.

Great! (And again: many thanks for doing this work).

> However, the runtests do not succeed on any of the 5 architectures.
>
> On win32-x86-static and windows-x64-static many of the tests
> succeeded, but in both cases it hung up in bittypeIoc.t.  I had to
> kill them with ^C.
>
> bittypesIoc.t .......... Starting iocInit
> iocRun: All initialization complete
> bittypesIoc.t .......... 1/24 ERROR: The process "softIoc.exe" not
> found. Terminating on signal SIGINT(2)
> Terminating on signal SIGINT(2)
> make[2]: *** [runtests.win32-x86-static] Error 130
> make[1]: *** [validate.runtests] Error 130
> make: *** [test.runtests] Error 130
>
> bittypesIoc.t .......... Starting iocInit
> bittypesIoc.t .......... 1/24 cas warning: Configured TCP port was
> unavailable. cas warning: Using dynamically assigned TCP port 65113,
> cas warning: but now two or more servers share the same UDP port.
> cas warning: Depending on your IP kernel this server may not be
> cas warning: reachable with UDP unicast (a host's IP in
> EPICS_CA_ADDR_LIST) iocRun: All initialization complete
> Terminating on signal SIGINT(2)

This happens often when running the tests immediately after building.
Normally it works fine when you run the tests again.

I have not yet found what causes these hangups. There must be some
subtle interaction between the Perl/system/exec/kill stuff and what the
IOC in the background does.

> The other 3 architectures (all dynamic) failed to run any tests
> because seq.dll was not found when trying to run the executables.
> The EPICS build system creates an IOC file called dllPath.bat, which
> can be used to define the PATH to find all of the required DLLs.
> This needs to be somehow incorporated into the test harness.

OMG.

Andrew, do you have any suggestions how to proceed? Is this documented
somewhere?

Cheers
Ben
--
"Make it so they have to reboot after every typo." ― Scott Adams

________________________________

Helmholtz-Zentrum Berlin für Materialien und Energie GmbH

Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V.

Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch, stv. Vorsitzende Dr. Beatrix Vierkorn-Rudolph
Geschäftsführung: Prof. Dr. Anke Rita Kaysser-Pyzalla, Thomas Frederking

Sitz Berlin, AG Charlottenburg, 89 HRB 5583

Postadresse:
Hahn-Meitner-Platz 1
D-14109 Berlin

http://www.helmholtz-berlin.de

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System