Survey: What development environment do you use?

Constantine:

On the Linux host, I find gedit to be the easiest to use.  Emacs and VIM have more capabilities for those

who are well versed in that.  Our new SDK for AM37xx / DM37xx ARM Cortex A8 MPUs is integrated with

an Eclipse-based IDE, which is a preview of CCS v5.  This is our first CCS offering that is Linux O/S aware.

The SDK include plug-ins that ease building projects at the application level based on the ARM cross-compiler

and Qt. 

We are working to make major improvements to our toolset and we are very interested in feedback about

features that the community would find useful to make the Linux experience easier.

Regards,

Michael T

PS: Please mark this post as answered via the Verify Answer button below if you think it answers your question.  Thanks!

Our goal is to be able to build 'the entire project' from a single ant command line.  The ant script is responsible for checking out (CVS, yuck!), building libraries, creating the rootfs, building the kernel, configuring the app, building the app, piecing it all together, etc... (Host tools are already installed on the local workstation - it seems overkill to checkout all the necessary tools.) The idea is that an entire workspace can be created from a single script, and nothing lives outside the 'base' directory such that any dev can have several, isolated workspaces going at one time.  Not necessary the norm, but possible. 

We use Fedora 8 for our dev environment.

When developing, most Linux users go w/ Emacs, VI, or other common editor.  I find eclipse is way to difficult to manage a non-eclipse based project.  My previous experiences w/ Eclipse haven't been all that productive, so perhaps that's my own issue.

For those even more curious, we manage changes to kernel and third party deliverables thru an overlay type system.  The delivered source is kept pristine, usually in a tar format, and a separate tree w/ full-file changes is copied over during the workspace setup.  This makes it easy to browse our local source and see what files have changed.  Since we don' store patches, it can make upgrading to a new package a little more difficult, but simplicity makes it worth it.

The TI DVSDK 4.0 (DM36x) is great for getting a virgin system up and running, but I'm finding it difficult to integrate into our existing way of doing things.  Hopefully I'll figure something out in the next few days. 

Hi Jason,

I would be interested to hear what your challenges are, we may be able to assist before our GA release. If you are using Fedora core 8 (which is quite old), the installer may give you some issues, and the setup script won't work as it requires Ubuntu 10.04 LTS. If you want to check in the DVSDK in to version control, I would suggest installing DVSDK 4.00 on a Ubuntu 10.04 LTS host (possibly e.g. virtualbox / vmware), running 'make clean' and 'make all', and then checking it in from there.

The setup script is not useful if you won't use the Ubuntu host for development, but it should serve as documentation on what you need to do manually on a Fedora core 8 machine. The rest of the DVSDK does not require a specific host, you should still be able to build against the components.

Thanks, Niclas

I'm still experimenting with how I want to handle integrating it.  I initially thought I would do it as you suggest by installing to a directory, then creating an archive (tar) and checking it in.  CVS is ridiculously slow when dealing with a large number of files (ie codec engine for some of our other products).  

From there, we'd create the overlay.  My concerns are how tightly the makefiles are integrated together with the rules.make, etc...  I don't fully understand yet what parts are dependent on each other wrt building, installing, etc....  I'm also not sure how I am going to handle the integrated gstreamer into the filesystem.  I was expecting to build gstreamer as part of the SDK - not having it integrated into the provided root filesystem.  I'm sure we'll need to tweak some things as the mpegts decoder doesn't appear to be working properly in the 10.25 version.

I'll gladly share any roadblocks and/or solutions/suggestions I come across as I venture down this project.  I appreciate your interest.  

Niclas,

In looking at the DVSDK4.x, I'm curious what the difference is between the linuxutils package (linuxutil_2_25_02_08) and ./psp/linux-driver-examples.  Both contain cmemk.c (with differences mind you).  

Which one is the 'correct' one to use?  I'm ...assuming... that I should be able to do use make and point to the kernel tree and build CMEM.  I've noticed that the cmem_install (and other related helpers like edma, irq, etc...) don't install into the module path such that depmod picks them up.  

Ideally, I would like to have those utilities perform just like any other 3rd party module; to be able to build them just like a module,  provide the install_mod_path  to make, and ultimately let depmod do its magic vs. having to build them outside the tree and manually copy them into the module tree so depmod will find them.  

I just started working this out, so perhaps I'll find my answer as soon as I hit post, but I am confused on the multiple cmem's in linux-utils and the psp tree.

Hi Jason,

I believe the team who did the examples included CMEM so that they would be self sufficient, but the right place to get CMEM from is "linuxutils".

We have discussed whether to overwrite the "factory default" cmemk.ko (edmak.ko...) when cmem_install is invoked, but at the time we felt it was dangerous to do this without explicit user consent. Feedback is of course welcome.

Regards, Niclas

I would argue that IF you are building the kernel and everything manually (ie, w/o the top top level make), then you have sufficient experience to understand that when you do an modules_install from the CMEM tree, that it will over-write existing files.

Of course, the counter to that is IF you are building the kernel manually, then you have sufficient experience to work around the fact that the module isn't installed in the correct place.  :)

I obviously am partial to having the modules work similarly to other 3rd party linux modules.  I'd much prefer all options be on the make CLI than in a common rules file with several options for a variety of components (ie Rules.make).

For instance, when making an archive of the installed SDK, there are several references to the original installation location.  At a minimum, I have to parse thru Rules.mk to change DVDSK_INSTALL_DIR (or at least override on the make CLI for this one), libtoolize for some pathing, and the environment setup to put the correct location for all the env vars.  

While trivial tasks, it IS a pita to do in an ant script/automated fashion.  

I'm coming from the aspect that we will likely need to make modifications to files, and have an [easy] method to rebuild as well as be able to make it brain dead simple that it can be done from a command line/ant - even if I have to build each piece separately (which I prefer).

After playing around a bit, I found a fairly simple, yet highly coupled method of controlling the build.

make  DVSDK_INSTALL_DIR=`pwd`  all

where `pwd` is the top of the DVSDK dir and where I can use the archived version of the SDK.  The only downside I have found so far is that the install,  

make  DVSDK_INSTALL_DIR=`pwd`  EXEC_DIR=`pwd`/staging install

works for everything except the dmai examples.  Those get stuffed into `pwd`/staging/install/ instead of `pwd`/staging/install/dmai... based on default behavior.  Not exactly power-user friendly, but it does build w/ a single line that I think could be run from an ant/automated script.

Now to verify this in another sandbox, and to see if gstreamer will build from svn w/ customizations.

What you did is what I would have proposed, every make variable can be overridden from the top. Looking at the top level DVSDK makefile, I don't see what the issue is:

dmai_install:
        $(MAKE) -C $(DMAI_INSTALL_DIR) PLATFORM=$(DMAI_PLATFORM) \
        EXEC_DIR_$(DMAI_PLATFORM)=$(EXEC_DIR)/dmai \
        install

Which platform are you on?

Regards, Niclas

DM365

For instance, when simply over-riding EXEC_DIR...

`[jtalley@jtalley-lin ti-dvsdk_dm365-evm_4_00_00_06]$  make -n DVSDK_INSTALL_DIR=`pwd` EXEC_DIR=`pwd`/../install dmai_install

Hi Niclas,

I've got a few questions regarding the env wrt a gstreamer based application.  A quick background - I have a gstreamer based app that I want to be able to build for Linux/x86 and/or Linux/ARM.  I'm using autotools to manage the builds/makefiles.

Ultimately, the question becomes how do I manage the paths hard-coded into libtool during the DVSDK installation process for application builds.

The scenario is as we've discussed above, I installed the DVSDK in a directory, and made a tarball that I untar into my [unique] workspace which is inevitably different than the original install directory.  The 'application' is a shared library + a test harness (executable).  I can build the shared library aspect fine b/c no linking is required. 

I have no problems using make to over-ride make variables.  I'm trying to address building an application using the SDK now.

When I setup my application directory, I use libtoolize -f -i -c/automake --add-missing/aclocal/autoconf to bootstrap the app directory tree.  The libtoolize from the DVSDK has references to the original install path which doesn't exist.  libtoolize fails to run if I run the SDK version.  If I use the host libtoolize(x86), the linker tries to link in the HOST (/usr/lib/) libraries which is obviously bad for an ARM app.

Any thoughts on how to overcome this issue?  Is replacing the hard-coded paths in the DVSDK libtoolize the best way to do this?  

I've tried the --response-file [arg] option for dvsdk_dm365-evm_4_00_00_06_setuplinux.bin to install the DVSDK into a new directory, but there is still user-action required which I need to avoid for automation.  

Jason,

I am not sure if the version of libtoolizer we used in DVSDK 4.0 had any environment varibale to listen when you relocate the prebuilt paths and to overcome that installer sed's the path based on the location you choose during install time.

Looks like in your use case, you are actually relocating the DVSDK install path and hence you need to update the libtoolizer prefix/datadir/pkgdatadir/aclocal to new path. A simple sed script like this is used in installer and you can do the similar in your case.

Brijesh

Good point.  Although my small over-rides and quick fixes are starting to add up.

I've already tweaked environment-setup a bit to use eval env -i `cat environment-setup` sh to create a clean shell to start from.   

I'm still crossing my fingers for an unattended installer.  :)  It might be easier to create an expect/perl script to 'automate' the installer than deal w/ all the tweaks.  I'm not sure how well that would play w/ ant (our build system of choice).

Jason,

If you could post the tweaks you had to do (or attach) that would be very helpful. We'd like to see how we can help power users in the GA release.

Regards, Niclas

Niclas,

So far it has been fairly mild.  To use my env line, I simply removed the export prefix for each line... ie

export FOO=bar

becomes FOO=bar

I don't use OpenEmbedded, so I'm not sure how that affects the other OE lines, or the alias line (I simply removed it).

I haven't decided how I am going to fix libtoolize.  Right now, I'm toying with making the following change to libtoolize:

prog=$0
execdir=`dirname $prog`
# Locations for important files:
SDK_PATH=${SDK_PATH:-${execdir}/../}
prefix=${SDK_PATH}
datadir=${SDK_PATH}/share
pkgdatadir=${datadir}/libtool
pkgltdldir=${datadir}/libtool
aclocaldir=${datadir}/aclocal
auxdir=
macrodir=
ltdldir=
configure_ac=configure.in

Hi Jason,

You can script the installer in console mode, use -mode console. If that is what you meant by "unattended".

Regards, Niclas

-mode console is just text mode which is what I will use if I go the expect/perl route.  By unattended, I'm looking for a method to put all the options on the command line and install in one shot w/o any user input.  For instance:

~/DVSDK4.0/dvsdk_dm365-evm_4_00_00_06_setuplinux.bin -compiler /opt/CodeSourcery -dest /home/jtalley/workspace/proj1021 -plat dm365

Where the compiler lives in /opt/CodeSourcery, the platfom is for DM365, and it will install everything to /home/jtalley/workspace/proj1021/ti*

This way, I don't have to build my own local archive and over-ride env variables, etc...  It would all just work.  Right now, I can't provide all the options to the installer on the command line.  Even the responsefile option doesn't do it all.  This allows me to script it from a makefile/ant/build server.   

Right now, when I run the installer, it asks me if I want to install the dvsdk on my computer and waits for input.

I see what you mean. We are using the same installer on all platforms, and dm365 happens not to have any components which require accepting an EULA (but other platforms do). For legal reasons the user must explicitly accept a EULA which is why we haven't pursued this further, but for dm365 specifically it's technically possible. As you say, using expect should work fine though.

Regards, Niclas

Just a thought, may be for now you can do something like this:

# cat  input

Y

/opt/arm-2009q1/bin

/home/brijesh/ti-dvsdk-dm365

# ./dvsdk_dm365_xx_xx.bin --mode console < input

Thanks

Brijesh

I am using CS light and Eclipse.

Do you have an idea, why EVM Board (Rev D) give so much strange messages with the recent PSP 3.0.1.6? See my seperate post for details (http://e2e.ti.com/support/embedded/f/354/t/62143.aspx=) 

Asked already Mistral and here in the board couple of weeks ago with no answer ... :(

Good idea, but no love.  It hangs when it prints the EULA.  I was hoping it was still working, but the target directory wasn't even being created.  Looks like I'll be getting friendly with expect in the near future.

I use normally vim through ssh.

I need to rebuild all my rootfs from an Openembedded command.

I have my overlay to add my processes.

I think that Arago is a good choice for DM365, even if actually the porting is not yet completed.

We are working on it and tomorrow we'll have some results.

The most important thing is to have gstreamer hw accelerated and a linux kernel compatible.

Also ubl and u-boot are important.

Eclipse can be nice to make gdbserver cross debugging (or SDK end-user programming) easier.

A DVSDK release is a good thing and can be checked on a EVM, but the most important thing is to be able to rebuild all.

For instance about dm365 DVSDK 3.10 release I was not able to rebuild arago-oe-dev.

I guess the tag was not correct (http://e2e.ti.com/support/embedded/f/354/t/61715.aspx)

I clean rebuild I think is important to be sure to be able to rebuild from scratch.

Looking at Openembedded this table seems nice: http://wiki.openembedded.net/index.php/Testing.

Also http://tinderbox.openembedded.net/ is a good way to monitor builds.

I also don't know Arago rebuilding issues are to be posted here or in arago-devel mailing list.

I sincerely prefer here, it seems to be more used.

I also like very much http://processors.wiki.ti.com/index.php/Main_Page where I can find always something interesting.

Also I like very much davinci-linux-open-source@linux.davincidsp.com mailing list for kernel development, and some of my patches have been accepted.

For Android I have seen a new forum here, but it is not clear if rowboat is better than it or maybe the Ti forum is only new and need to be used.

I hope something useful is contained is my post,

Raffaele

I use bash shell and configuration scripts for managing build environments. VIM for editing. Utilities ctags, grep, find for searching source code. Git and svn for source control.

I noticed some community members offered improvements and tips for DVSDK in this post. Here is dedicated thread for this hot topic: What could you offer to improve DVSDK?