Deleted copy constructor in external project not respected during Trickification

[ninotarantino]

I ran into this edge case today. I have a workaround I'll post at the end, but I thought I'd let the Trick team know. FYI, I'm seeing this in Trickified classic (pre Trick 25) and the newer trick-ify with Trick 25. I'll post the "classic" example since it's a bit easier to show.

Environments I reproduced this on:

• Rocky Linux 8.10 (SWIG version 3.0.12)
• Debian Linux 13.3 (SWIG version 4..3.0)
• Trick 19.8.0 and Trick 25.0.3-beta on both OSes

Tagging @ddj116 for awareness.

Background

I have a library that I want to Trickify. It heavily depends on JEOD, which already provides its own Trickification makefile. So the idea is that I'll declare JEOD as part of my TRICKIFY_EXT_LIB_DIRS. Then I only Trickify my headers, and users can choose whether they want to also Trickify JEOD or build it with the normal Trick build process.

Here's my makefile:

TRICKIFY := $(TRICK_HOME)/share/trick/makefiles/trickify.mk

export TRICKIFY_OBJECT_NAME := cml_trickified.o
export TRICKIFY_CXX_FLAGS := -I${CML_HOME}/models -I${JEOD_HOME}/models -I${TRICK_HOME}/include -I${TRICK_HOME}/trick_source
export TRICKIFY_PYTHON_DIR := python.zip
export TRICKIFY_EXT_LIB_DIRS += ${JEOD_HOME}
export ICG_EXCLUDE := ${JEOD_HOME}

all:
        @$(MAKE) -s -f $(TRICKIFY)

clean:
        @rm -rf build ${TRICKIFY_PYTHON_DIR} full_file .trick $(TRICKIFY_OBJECT_NAME)

But when I try to build my Trickified library, I get the following error (paths obscured for brevity):

lviy_derived_state_py.cpp: In function 'PyObject* _wrap_LviyDerivedState_lhiy_frame_get(PyObject*, PyObject*)':
lviy_derived_state_py.cpp:5453:32: error: 'RefFrame& RefFrame::operator=(const RefFrame&)' is private within this context
   result =  ((arg1)->lhiy_frame);

SWIG isn't respecting that JEOD's RefFrame class's copy constructor and copy assignment operator are deleted.

Workaround

If I Trickify JEOD first, then add export TRICK_SWIG_FLAGS += -I${JEOD_HOME}/trickified to my project's Trickification makefile, everything behaves properly. That means I do need to mandate that users of my project Trickify both it and JEOD since the resulting .d file for my headers will reference the JEOD trickification products. I'd still prefer the full independence from JEOD, but this is sufficient for now.

Simple Example

Here's a simple, fully independent version of my example from above:

trickify-bug.zip

I have two trickified projects, foo and bar. bar depends on a header from foo. If you try to Trickify bar first, the build fails. If you trickify foo first, then bar succeeds.