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.

How to ensure a custom platform is built before a project builds?

Hi

I am running CCS 5.1.0.09000

I realise that a custom platform is automatically built whenever it is modified using the RTSC Platform Wizard.  However, in our development environment we store our source files in Subversion (version control system). It is possible that developer (A) will commit a modified Platform.xdc file to the repository and another developer (B) will update to the changed version, without running the platform wizard.  In this circumstance, how can I ensure that the platform will be rebuilt when developer B rebuilds his local copy of the project?

Best regards

David

  • Keep these files checked in to version control once the Platform is created with the GUI:

    config.bld

    package.bld

    package.xdc

    Platform.xdc

    Platform.xs

    All other files (.libraries, .executables, etc) are generated at build time each time you build and should not be version controlled.  If the platform is changed by developer A, developer B getting the latest revision will change the above files.  When the project is rebuilt by developer B, the executable will use the new settings.

  • David,
    the answer depends on the workflow in your team. If you normally build packages on the command line, as you had to do in the other thread, then Nick's advice applies. Even if you mostly use the Platform Wizard, but you don't mind rebuilding the package on the command line every time you check it out from a version control system, you can still keep only the sources under version control.
    However, if you only change platform packages, and you change them only using the Platform Wizard, and you don't want to ever build from the command line, then you might need to keep everything in the platform package under version control.

    If you keep only the source files under version control, and you check out the sources into a new directory, the Platform Wizard won't find the platform because the Wizard must be able to read the content of the directory 'package' to recognize that a package contains a platform. If you check out the sources into a directory that already contains an already built platform package containing the directory 'package', the content of the directory 'package' could be outdated, but it would be still displayed in the wizard. Any further change will be written over the checked out file Platform.xdc.

    If you keep everything under version control, every time someone changes the platform in the Platform Wizard, the package will be rebuilt and the content of the directory 'package' will be in sync with Platform.xdc. They weren't in sync in the other thread because one file is missing from 'package', but if you keep 'package' consistent, the Wizard will rebuild the whole package whenever needed.

  • Hi Nick and Sasha, thanks for your answers.

    Sasha, thanks for tracking me here from my previous thread. I thought it best to start a new thread because I marked the other one as answered. From your replies, I can think of two ways forward presently:

    1) Add package.xdc.dep to version control.  Actually, I haven't made this work - after adding it I still get the problem reported in the previous thread.  But I think this has to do with xdc.exe clean upsetting the version control by deleting metadata in the package folder.

    2) Following Nick's advice. Commit the bare minimum files to Subversion and use xdc.exe to build the platform. But I don't really want every developer to have to remember to do this.  This brings me back to my original question in this thread.  Can I add a make dependancy in the CCS project to invoke xdc.exe on the platform whenever I build the project? 

    David

  • 1) If you have package.xdc.dep, and the java file is not rebuilt even after you update Platform.xdc, I would like to take a look at that package. 

    2) You can create a separate project that rebuilds the platform package every time you build your main project. Your platform project should be created as a "Makefile project with existing code". You’ll have to specify ‘xdc’ as build command for that gmake project. See “Build command” below.

    Then, in the main project, in Properties->CCS Build->Dependencies, add your platform project as a dependency.

  • Hi Sasha

    1) I have now fixed the problem with including package.xdc.dep in version control.  I was running a version of xdc.exe from the command line that was different to the version used in CCS 5.1.  I have now used the same version and package.xdc.dep is in version control. This seems to be an adequate solution.

    2) Thanks for your suggestion of using a dependant project. That helps my understanding.

    I think I am sorted now. Thanks for your help.

    David

  • Thanks for this thread, I've been struggling with the same issue.

    For TI, I think there are three "pain points" here with CCS, all of which could use a little work:

    (1) Making xdc.exe play nicely with Subversion.  It's OK if you only check in sources, but checking in "built" packages causes problems.  (a) it isn't clear which files you need, and (b) "xdc clean" deletes the package/ subdir which annoys and confuses SVN.  If you can't check in the build package, then everyone who checks it out HAS to be able to build the platform package.

    (2) The platform wizard isn't integrated with the Project settings or makefile generation, whereas sometimes it would be really nice just to check a box and say "this platform.xdc is part of this project build".

    (3) The absence of direct and obvious support for xdc-built component packages in CCS is mystifying, given their importance in the TI narrative.  Yes, I know you can treat XDC as a custom-makefile tool as in the (helpful) example given, but surely CCS could be a bit more aware than that?  (This is a generalisation of (2), to other kinds of XDC-built packages, especially libraries)

    (4) At least for the C66xx Keystone devices, the platform de-facto includes important linker memory map definitions that cannot be overridden in the .cfg file.  This is what creates much of the software coupling and the need for the platform to be updated most often for us.  If the semantic rather than hardware aspects could be decoupled, you would have less need to fiddle with the platform package and could use the "stock" EVM platforms more.

    My ideal would be for the "platform" package to define physical ranges for "DDR3", "L2SRAM", "MSMCRAM" etc. and .cfg file be able to define named subareas of these as linker section.  At present this is not quite possible, so you end up doing things like the following (from the MCSDK!) which is effectively an application-specific partition of the MSMCRAM physical area, and therefore the application requires a custom platform even on an EVM.  It also includes things like access bits and L1 and L2 cache sizes that cannot be overridden in the .cfg, but again are really application-specific settings rather than attributes of the hardware platform.

                    ["MSMCSRAM_MASTER",
                         {
                            name: "MSMCSRAM_MASTER",
                            base: 0x0c000000,                    
                            len: 0x00100000,                    
                            space: "code/data",
                            access: "RWX",
                         }
                    ],
                    ["MSMCSRAM_SLAVE",
                         {
                            name: "MSMCSRAM_SLAVE",
                            base: 0x0c100000,                    
                            len: 0x00100000,                    
                            space: "code/data",
                            access: "RWX",
                         }
                    ],
                    ["MSMCSRAM_IPC",
                         {
                            name: "MSMCSRAM_IPC",
                            base: 0x0c200000,                    
                            len: 0x00200000,                    
                            space: "code/data",
                            access: "RWX",
                         }
                    ],

    OK, rant over for now.  :-)

  • Hi Gordon

    Thanks for your analysis of the problem. I hope that TI takes notice.

    Best regards

    David

  • Gordon,
    thanks for your rant post, it does bring up some issues that we would like to address, but as everyone else we have to prioritize work items based on how loudly customers ask for them. Without promising anything about future enhancements, I'll try to comment on some of the topics in case you can solve some of the problems with the current tools.

    1) When the Platform Wizard builds a platform package, it also creates a zip file which contains all the files needed to use the platform. So, the users who do not make any changes could only check out the zip file, extract the files and use the platform without building it. So, if you keep the sources and the zip file under version control, you could avoid the need for rebuilding at least for some users, and also avoid checking in the directory 'package'.
    I am not sure what we could do to make XDCtools create svn-friendly packages. If the problem with svn and the removed directories is caused by the removed .svn directory inside the directory 'package', then upgrading svn may solve the problem because I think they switched to one .svn directory on the top instead of .svn directories everywhere.

    2) I would also like to get there sooner rather than later, where you would say "this platform package is part of the project build", and 3) would be "this <whatever> package is part of the project build". I am not aware of any plans for that right now, but that could change. 

    4) This is actually a common request because that's how DSP/BIOS 5 worked. The difference is that now the config script is not exclusively a SYS/BIOS config script, but there could be multiple packages involved in a configuration (BIOS, IPC, cfg script as a part of a special package, NDK, possibly others), and each of these packages could contain some logic that depends on the content of the memory map. Therefore, the map can't change as soon as any of the packages had a chance to read it, which could be the first statement in the script.
    Currently, we solve it by defining the memory map in a platform package, which then prepares the memory map before the script starts and makes the map readonly in the config script. We are looking for better alternatives, and this item is most likely to get a lot of our attention soon.

  • Fair enough, I was having a rant, and don't mean any offense.  Believe it or not, I'm actually defending CCS around here now.  Some of my colleagues had a bad experience with a CCS 4/C64xx project a few years ago and won't go near it, but I'm actually coming to like the tools.  With a few reservations ;-).  I also think it's easy on forums like this to focus on the immediate problems people express rather than the broader design issues that would fix them properly, and I liked this thread because it was a bit more "big picture".

    Under (1), I'm aware of the ability to do release/install steps, but haven't managed to build that into our workflow.  The DSP code is part of a larger SVN tree and people want to be able to "check it out and just build it".  I think if you managed to decouple the application-specific memory map from the platform details as you discuss under (4), then this would work better.  We would then only have to issue a new platform very occasionally (eg. along with a board spin) and could use the RTSC versioning to detect if people hadn't upgraded.  On the EVMs, I could imagine not having a custom platform at all and just using the xdctools package, which would be great.

    Regarding newer SVN working better with XDC, I didn't know that, but will certainly try it.  Thanks for the tip.

    For now, I like the technique you posted above (22 Mar) of having a separate project in the workspace which builds the platform, and will try to implement it when I get a chance.  (Rant aside, this isn't actually a day-to-day problem at present).

    Regards,

    Gordon

  • As a further note, creating a "Makefile project with existing code" in CCS 5.1 just didn't seem to work.  The "Build" options were entirely missing, and the .project file created was totally gutted as below.  In particular, comparison with working projects suggests that the <buildSpec> section is AWOL.  I needed to create a non-CCS "C/C++" project with an arbitrary toolchain and then select an external build tool.  This was a bit non-obvious but seemed to work.

    <?xml version="1.0" encoding="UTF-8"?>
    <projectDescription>
        <name>testC6678</name>
        <comment></comment>
        <projects>
        </projects>
        <buildSpec>
        </buildSpec>
        <natures>
            <nature>org.eclipse.cdt.core.cnature</nature>
        </natures>
    </projectDescription

  • Gordon,
    I folowed these steps and it all went smoothly for me:
    1. Create a new platform in the Platform Wizard
    2. Right-click in Project Explorer->New->Project...->Makefile Project with Existing Code
    3. Browse to the directory with the existing platform, select it and click Finish. Also leave Toolchain as <none>.
    4. Right click on the new project->Properties->C/C++ Build and unselect "Use default build command"
    5. Type ${XDCROOT|/xdc release as a new build command

    I can now click on Build Project and Clean Project, and everything worked. Then, I can go to another project and follow these step to make that project dependent on the platform project:
    1. Properties->CCS Build->Dependencies->Add ... and choose the platform project, then OK
    2. Project->Build Project now goes and rebuilds the platform project first, if needed, before building this project.

    When you say that the "build" options were missing, what do you refer to? When you created a new Makefile project and right-click to it, were the build options grayed out?

    I am using 5.1.0.09000 and XDCtools 3.22.04.

  • Aha.  I had been selecting "TI Build Tools", which was not generating the .cproject and only the very minimal .project above.  If I select Toolchain <none>, then it works.

    I think my logic had been that XDC is part of TI Build Tools, and therefore assumed that choosing that toolchain might help set up paths for XDC or whatever in a way that <none> might not.  Obviously not.

  • Hello,

    I am sorry for hijacking someone's thread and rise new questions in what has been marked as resolved, but this thread already defines problem well, so I hope my voice would be heard too.

    My concern is again about source revision control. In my company we also use SVN to distribute sources among developers. Though we don't mind some binaries to be checked in, I prefer to store sources only and build all required binaries on demand.

    I came here with custom platform defined. From above discussion I picked up, that there is a possibility to create makefile project to build platform. I have created such a project in the folder where platform stuff resides. I left under revision control following set of files:

    .cproject
    .project
    config.bld
    package.bld
    package.xdc
    Platform.xdc
    Platform.xs

    Then I was able to build this project and platform stuff get created. Fine so far.

    Now let's get back to original problem. We want developer checkout the project, build it and everything get spinning. The problem is that if I want to set 'make_platform' project as dependency to main project, this 'make_platform' should exist in the CCS workspace. However, workspace is what supposed not to be checked into revision control. Please suggest, how to define dependency within project, not workspace.

    Minor question is that build clean for this 'make_platform' project cleans nothing.

    Perhaps, there is some intended design flow kept in mind by TI, would appreciate advices.

  • The project that rebuilds the platform has to be a separate project, but it does not have to be in the CCS workspace. For the example I created above I kept the platform in C:/temp/platforms. I may be misunderstanding your question, do you want to have all platform files within your app project? How would different app projects share a platform then, and also aren't app projects in the workspace already?

    In my make_platform project, this is the output I get when I righ-click on the project and then Clean Project:
    0:43:14 **** Clean-only build of configuration Default for project platBuild ****
    "C:\\ccs54\\xdctools_3_25_01_54_eng\\xdc" release clean
    all files complete.
    generating external release references package/rel/tisb_my64board/tisb/my64board/package/package.rel.xml ...
    generating schema include file list ...
    10:43:17 Build Finished (took 3s.7ms)

    All generated files are removed after running this command, which is what should happen. What's in your console window when you clean that project? Does the directory 'package' still exist on the disk?

     

  • Hello Sasha,

    Let's start with the last issue. I double checked behaviour of make_platform project and must confirm, that 'build clean' actually deletes 'package' directory. Now it works stable and repeatable for me, so there is no problem at all.

    As to the first one, let me clarify. Same to you, I have independent project to make platform. What I want is to set this 'make_platform' project as dependency to application project. Suppose, I have a workspace with app_proj and make_platform. Then setting app_proj to depend on make_platform is straightforward: within workspace we can set up dependencies.

    Now assume I share the code with colleague. I check in sources and project files, but not workspace. So my colleague checks out sources and project files. He may check out app_proj. He opens app_proj in his own workspace and tries to build it. He will receive just error that dependent project is missing, but there is no information where that dependency might be located.

    My ultimate goal is to check into revision control system sources and projects in a form, that any collaborator can check out all source tree and build all required software in a click, including any dependencies. I want something like MS Visual Studio solution file, which can be placed under revision control and then distributed among developers. Perhaps its possible, but I don't know how to do that. What I know is that Eclipse workspaces is not what expected to be shared. Please suggest proper way to do that.

    Thank you.

  • I don't know exactly how MS solutions work, but it seems you want to import one item (solution) that contains multiple projects. In other words, you don't want your colleague to separately import both app_proj and make_platform. When you are importing a project, there is a checkbox "Automatically import referenced projects". I have never used it, so I can't tell how it works, and CCS also has something called "Team Project Set", which could be what you are looking for.
    However, I am not expert for these topics and you'll certainly get a better answer if you start another thread in the CCS forum

  • Hello,

    Thank you for your efforts. I have started a thread in suggested forum.