Page 1 of 2

MPLAB X in a team setting

PostPosted: Tue Jul 29, 2014 11:44 am
by yubyub
Hello, all.

I've just recently started to move our firm over to MPLAB X from another compiler, and had a question about working as a team in this environment.

Based on what I've experience thus far, MPLAB X likes to store relative or absolute references to all files involved in a project. This works great for the source of the project (i.e. your app.c, app.h, etc), but I foresee problems over things such as including Harmony and other such frameworks.

For example:

I use Windows 7. Another coworker uses Linux. We organize the library sources slightly differently, i.e. I have Harmony in C:\Microchip\Harmony\<version>, while my coworker has it in ~/src/harmony/<version>.

We also have a set of dedicated build machines, which we use to build our production source. Some of these are used to evaluate different framework versions, i.e. compile and regression test code compiled on a new version of Harmony that we haven't certified yet.

So, I have a need to determine the best way that "external" files can be "pointed to" instead of included via relative and absolute paths. In other compilers, there are tons of Makefile tricks to do this - even coming down to simple things such as environment variables. I can't, as of yet, see how to accomplish this in MPLAB X.

I'm sure this is somewhere in the documentation, but I sure can't find it yet.

Is there someone who can illuminate me as to the Right Thing (TM) to do here?

Many thanks.

Re: MPLAB X in a team setting

PostPosted: Tue Jul 29, 2014 2:19 pm
by Tom Maier
It's been many years since I've done team programming, and I haven't used Harmony, but the old rules of team development we had were:

1.) everybody needs to be in the same identical environment, using exactly the same set of tools and version numbers.

2.) one person is the "master collator/builder" who brings the team members code together and makes sure everything plays together. If this person is not able to build the code, then he needs to fix it and ripple the fix back to the person who is creating the problem. One person assigned to this job prevents divergence and arguments.

3.) when there is a production release,, the whole she-bang is saved off and archived, which includes all the tools used to do the build and a notes file or main source file header that describes the whole build process.

It's really common to encounter a company that is in hot water because they have some old source code, but nothing else and they don't remember the tools they used or parameter settings to create the build. That's another thing with some of these IDEs, they sometimes have some parameters settings in the IDE settings that aren't in the generated make files, so even if you have the make files there is information missing to actually do an identical build the way they did it before when you only ave the source and make files. The IDE was set up to do some things and when you do a virgin install of the IDE, those settings are no longer there so you have a guessing game as to how to set up the IDE to do the old build.

Re: MPLAB X in a team setting

PostPosted: Tue Jul 29, 2014 4:07 pm
by yubyub
Tom,

Thanks. We solve (1) and (2) by using automated builds on locked down machines, with regression tests on a locked down machine as well. Nothing goes out that doesn't build or test properly.

I'm wondering more on how to deal with variation in the desktops.

Re: MPLAB X in a team setting

PostPosted: Tue Jul 29, 2014 4:17 pm
by Tom Maier
Most all companies don't allow varitaions in the operating systems. I like linux, but I've never been allowed to use it before. I'm surprised it is allowed there. (...to run different OSes on development machines, not to allow just linux).

I would go with only one exact OS, at a specific version and patch level.

That should start a war between the windows and linux people, but it will minimize your technical problems.

Re: MPLAB X in a team setting

PostPosted: Tue Jul 29, 2014 5:03 pm
by JoshuaHartwig
My team has had some success with MPLab X by incorporating Git as our VCS. There's a section in the user guide that spells out exactly which folders and files need to be saved to allow another computer to open and build the project. The Package feature is a shortcut to finding out this information. If the project is packaged the same way on every machine, it's easier to manage. We then can push our commits to a server and review each others' work via pull requests.

However, we do not use Harmony or any of the older libraries/frameworks and all of my teammates are running Windows. There have been several threads on the MChip forum where people have struggled to get the Package and Move features working in MPLab X, and all of them seem to have been using Harmony. I have no idea what additional problems you might run into trying to synchronize with different project setups, Harmony, AND different OSes.

Re: MPLAB X in a team setting

PostPosted: Tue Jul 29, 2014 5:09 pm
by yubyub
Joshua,

Thanks a ton - I'll try to find that section in the documentation.

All the advice is much appreciated.

Re: MPLAB X in a team setting

PostPosted: Tue Jul 29, 2014 6:02 pm
by Tom Maier
Don't tell your work crew that I'm the one who suggested using only one operating system. I don't want to be the target of a holy war. =-}

Re: MPLAB X in a team setting

PostPosted: Tue Jul 29, 2014 6:18 pm
by yubyub
Tom,

Too late. I told them already. They have gathered their pitchforks and torches, and are marching towards you.

And they look angry.

;-)

Re: MPLAB X in a team setting

PostPosted: Tue Jul 29, 2014 6:30 pm
by Tom Maier
GET BACK!!!

I HAVE OPENBSD AND I'M NOT AFRAID TO USE IT!

bsd.jpeg
bsd.jpeg (4.22 KiB) Viewed 8920 times

Re: MPLAB X in a team setting

PostPosted: Wed Jul 30, 2014 6:25 pm
by JoshuaHartwig
I have no quarrel with your potentially superior [firepower] OS, only with the hallowed command line.