• Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 350 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Why doesn't my IUNIVERSAL codec/algorithm properly 'clean'?

Richard von Lehe58975
Intellectual 470 points

I'm comparing an algorithm to other canned algorithms from the DVSDK (4_03_00_06), such as aachedec.  When I build at the top-level, 'make codecs_clean', it does nice things, whereas my codec doesn't get cleaned.  My algorithm is ultimately getting included in the clean, which boils down to a '$(XDC) clean' command with XDCARGS="prod".  Unfortunately, with the default configuration of the algorithm, this command does nothing.  (see below)


======== clean [packages/fluke/imagecor] ========
======== clean [packages/ti/sdo/codecs/aachedec] ========
rm -f package/ti.sdo.codecs.aachedec.sch
rm -f package/.vers_g160
rm -f package/.vers_r170
rm -f package/.vers_b150
rm -f package/.vers_c150
rm -f package/.xdc-u17
rm -f package/ti_sdo_codecs_aachedec.java
rm -f package/ti_sdo_codecs_aachedec.class
rm -f package/package_ti.sdo.codecs.aachedec.c
rm -f package/package.defs.h
rm -f package/package.doc.xml
rm -f package/ti.sdo.codecs.aachedec.ccs
rm -f ti_sdo_codecs_aachedec.tar
rm -f package/rel/ti_sdo_codecs_aachedec.xdc.inc
rm -f package/rel/ti_sdo_codecs_aachedec.tar.dep
rm -f .libraries .libraries,*
rm -f .dlls .dlls,*
rm -rf package

All of the pertinent 'clean' target information gets stored in a package.mak folder under the codec's directory (e.g. aachedec/package.mak).  That file seems to be temporary, though.  There is no equivalent for my wizard-generated algorithm. 


How can I easily mimic what the canned codecs have in terms of the ability to be cleaned from the top-level 'make codecs_clean' command.  There's some magic here that I'm not understanding.

I can continue to develop easily on my machine by hand-removing the output files when I want to rebuild the codec server.  That works, it's just a bit clunky and isn't a good long-term solution if this is going to be worked on by more than just me, which is likely.

  • Intellectual 470 points
    Some more information on this:

    The UNIVERSAL algorithm shell that I created via the wizard has a makefile in the package folder. There are slight differences in the 'xdc' call to build my package versus the vanilla (no arguments) xdc call made from the CODEC_INSTALL_DIR makefile.

    If I run 'make' in my package folder, then 'make codecs' from the top level, everything gets built just fine. Also a 'make codecs_clean' works. It's just that calling 'make codecs' from the top-level doesn't do enough to build my package, presumably because I need extra command-line arguments in the 'xdc' call.

    Below is the makefile pretty much verbatim from the codecgen wizard. What I will probably do is move my package to another repository. Chris Ring suggested this in another thread. I don't fully understand why the extra arguments to the 'xdc' call make everything work (i.e. I get the package.mak file generated). Then I can use a separate makefile to build this and any future algorithms of my own using a separate makefile as a first step. This would be followed by the 'make codecs' that would then integrate the TI codecs (jpeg and h264) along with my algorithms into the final codec server. Hopefully this will work.

    ---------------------------------makefile---------------------------------------------------
    # your various installation directories
    XDC_INSTALL_DIR=~/gemini/ti-dvsdk-4_03_00_06/xdctools_3_16_03_36
    CE_INSTALL_DIR=~/gemini/buildroot/fluke/packages/ti-dvsdk/codec-engine_2_26_02_11
    XDAIS_INSTALL_DIR=~/gemini/ti-dvsdk-4_03_00_06/xdais_6_26_01_03
    CODEGEN_INSTALL_DIR=~/gemini/ti-dvsdk-4_03_00_06/cgt6x_6_1_14

    #uncomment this for verbose builds
    XDCOPTIONS=v

    # If we're a subcomponent, allow larger product settings to override our
    # defaults. The variable $(RULES_MAKE) can be overridden on the 'make'
    # command-line if the location below is not correct (for example, if you
    # want to use a Rules.make from some other location.
    RULES_MAKE := $(CE_INSTALL_DIR)/../Rules.make
    ifneq ($(wildcard $(RULES_MAKE)),)
    include $(RULES_MAKE)
    endif
    CGTOOLS_C64P=$(CODEGEN_INSTALL_DIR)
    XDCARGS=CGTOOLS_C64P=\"$(CGTOOLS_C64P)\"

    XDCPATH=$(CE_INSTALL_DIR)/packages;$(XDAIS_INSTALL_DIR)/packages

    all:
    "$(XDC_INSTALL_DIR)/xdc" XDCOPTIONS=$(XDCOPTIONS) XDCARGS="$(XDCARGS)" --xdcpath="$(XDCPATH)" release

    clean:
    "$(XDC_INSTALL_DIR)/xdc" clean
  • in reply to Richard von Lehe58975
    TI__Expert 7250 points
    We’re closing out this old thread. If you feel there is more discussion on the topic, please feel free to "Reply".