Trickifying unintentionally includes dependencies

[excaliburtb]

The line here,

trick/share/trick/makefiles/trickify.mk

Line 118 in 0a1a092

TRICK_EXT_LIB_DIRS :=

ends up clearing up some exclusions I actually want to prevent multiple definitions when I'm trying to trickify multiple submodules.

[jdeans289]

We will look into this. We will need to determine why it was designed this way in the first place; we'll get back to you.

[dbankieris]

I believe I added that line to allow a sim using Trickified code to build that code as part of its own build. The end of the wiki page on Trickification recommends that a Trickified project's user-facing makefile contain the following lines:

# Enable Trickification support if Trick >= 17.1.
# Otherwise, let Trick generate all of the io_* and *_py code as usual.
ifneq ($(wildcard $(TRICK_HOME)/share/trick/makefiles/trickify.mk),)

    MYPROJECT_TRICK := $(MYPROJECT_HOME)/trickified/trickified_myproject.o

    # Tell Trick the headers and source at this location are part of a
    # Trickified project
    TRICK_EXT_LIB_DIRS += :$(MYPROJECT_HOME)

    # Tell Trick where to find the zipped Python modules generated by SWIG
    TRICK_PYTHON_PATH += :$(MYPROJECT_HOME)/trickified/python

    # Tell SWIG where to find *_py.i files
    TRICK_SWIG_FLAGS += -I$(MYPROJECT_HOME)/trickified

    # Link in the Trickified object
    TRICK_LDFLAGS += $(MYPROJECT_TRICK)

    # Append a prerequisite to the $(SWIG_SRC) target. This will build the
    # Trickified library along with the sim if it does not already exist. Using
    # $(SWIG_SRC) ensures that all Trickified .i files are created before SWIG is
    # run on any simulation .i files, which may %import them. Note that this does
    # NOT cause the Trickified library to be rebuilt if it already exists, even if
    # the Trickified source code has changed.
    $(SWIG_SRC): $(MYPROJECT_TRICK)

endif

$(MYPROJECT_TRICK):
        @$(MAKE) -s -C $(MYPROJECT_HOME)/trickified

A user of this Trickified project is expected to include this makefile from their S_overrides.mk. This makefile sets TRICK_EXT_LIB_DIRS so that Trick will recognize this project as Trickified code. It then adds this project as a dependency of $(SWIG_SRC), causing this project to be built as part of the sim build if necessary. Because TRICK_EXT_LIB_DIRS is exported in Makefile.common, trickify.mk has to clear it out or it would be unable to Trickify the headers that it was just invoked to process.

TRICK_EXT_LIB_DIRS was meant to be used to exclude headers during a simulation build, not during Trickification itself, which is controlled by the contents of the Trickified project's S_source.hh.

@excaliburtb Can you elaborate on your scenario? Are you trying to Trickify code that includes other, separately-Trickified code? I had not previously considered that use case and can see how it would run into problems.

[excaliburtb]

Yes, the issue for any model package that has a model dependency is that the resulting trickified lib is compiled as a static lib and will result in multiple definitions during final linking of the sim.

For example, many of the coredyn products uses a criticalthreads package. I can't trickify any of them due to this issue since the final trickified lib will include the headers of the product and its dependencies.

I see 2 potential solutions, compile the trickified lib as a shared lib instead OR respect the TRICK_EXT_LIB_DIRS passed into the trickify.mk AND change the makefile in the users trickified directory to include clearing the TRICK_EXT_LIB_DIRS variable.. which is where the clearing really needs to occur.

something like that maybe...

[dbankieris]

You can create a shared library by setting TRICKIFY_BUILD_TYPE to SHARED. But I think you're right that the clearing/overridding of TRICK_EXT_LIB_DIRS should occur in the trickified project's makefile rather than trickify.mk.