• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 397 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.

Never ever ever ever Never ever Never Never

Helmut Forren
Mastermind 6805 points

WARNING:  On a Linux development host, Never ever ever ever Never ever Never Never try to use one of the makefiles in DVSDK 3.10 (and probably others) aside from the primary makefile in the higher level folder next to Rules.make.

The individual makefiles are just too convoluted and too sensitive to work without loads of trouble and wasted time.  This is even in SPITE of the instructions that come with things like DSP Link, which suggest using lower level makefiles.  For DSP Link, don't follow the instructions.  Just run "make dsplink" or "sudo make dsplink" at the top level.

And when it comes to a Windows XP development host, I'm not sure if that high level make works, either.  There seem to be many slash problems (forwardslash versus backslash), as well as differences in opinion as to where files MUST be installed for CCS vs DVSDK.  I had to brute force the makefiles under CCSv4 and finally get things working just to compile a codec and server.  I don't have the time to try again going from the DVSDK top level makefile.

NEVERTHELESS, note that this top level makefile in DVSDK comes with its own problems.  Mine still won't run all the way through without error when I simply try "make".  This is one reason, combined with the instructions for DSP Link found in the UserGuide.pdf, that I didn't get things done in the beginning by the top level make.  I had to separately do the "sudo make dsplink" (sudo for me) and "make demos" to get things working.  Note my objective in all this was to do little more than tweak the ividanalytics_copy codec and the encodedecode demo, then rebuild them to try out on the EVM.

-Helmut

P.S. Sincere sincere thanks to many folks who helped me along the way.  I know a lot more about the "surface streets" (that I really had neither time nor therefore need to learn, unfortunately).  But now I just ran on the express freeway to get very close to where I need to be on this project.

ADVICE TO TEXAS INSTRUMENTS: On the next DVSDK release, add a special internal env var that the top level makefile sets to point out the fact that it's running.  Then in EVERY makefile anywhere in the DVSDK, check for that env var.  If not present/set, output an obvious warning (like surrounded by * or = chars) that things will be much, much easier if you run the top level makefile.  Even give advice as to the parameter to pass, such as "make demos" advice coming from encodedecode/Makefile.

  • 0
    Expert 2995 points

    Yes, DVSDK build system is not enough good. It is overcomplicated, redundant and don't use professional approach.
    For my projects, I define my own environment, based in on so-called "Rules".

    BTW:

    • file "Rules" intended to to store rules, not environment defines.
    • In good organized project, each subproject can be built without main make file. It is important developing derived projects.

    If TI would like, I can give advices and preform redesign of DVSDK build system.

  • 0 in reply to Constantine
    TI__Expert 6850 points

    Note that WinXP is not a supported development host for the DVSDK and there are no plans to expand the Linux DVSDK to include such support.  A step function improvement was made in moving from previous SDKs to the 4.x releases.  If possible, I would suggest you move to the latest version available today, i.e. SDK 4.01 unless you are using a device which is not supported by that release.

  • 0 in reply to Jeff Hayes
    Mastermind 6805 points

    I must clarify what you say.  I'm using both Windows XP and Linux.  My use of Windows XP is strictly driven by the documentation on the wiki and advice on the forum.  For example, they are both full of references and instructions for CCS, which to my understanding works only on Windows, and this includes XP.   I believe the only way to debug a codec is using CCS.  

    With that said, your comment must refer strictly to DVSDK's makefiles.  I can see those being only for Linux.  But in the broader sense, should not the "DVSDK" include the whole combination of tools, such as dsplink, codec engine, etc?  DSP Link, documentation, for example, speaks specifically of using a Windows host, including XP.  Various codec tools are designed to work on Windows (XP):  QualiTi, GenCodecPkg, GenServer.

    So, perhaps strictly speaking, the compressed file downloaded as "DVSDK" might not include this Windows XP support.  But plenty of Windows XP support abounds.

    In the end, thanks for your comment.  It will surely give many people insight into how poorly aspects of, or at least surrounding, the DVSDK, work on Windows XP.

    -Helmut

    P.S. My original second paragraph indeed leads with a sentence you can justifiably rebut. The forward slash and backslash problems, however, still exist and they exist with things documented for Windows, again including QualiTI, GenCodecPkg, and GenServer.