3 ms·

What if the problem actually is complex? Let's say that I'm building an embedded firmware module for a chipset that can only be compiled with a proprietary com

by bdamm 12y ago

What if the problem actually is complex? Let's say that I'm building an embedded firmware module for a chipset that can only be compiled with a proprietary compiler under Visual Studio - and you're a Unix shop with Bamboo as the continuous integration server? Then that means the Unix bamboo server needs a Windows agent that can execute the cross-compiler inside a MS VC environment. It certainly is complex, but what piece are you going to change?

fragmede 12y ago
Honestly? Port it to GCC. (Easier than LLVM, IMO) That, or switch to a different chipset, this time taking care to select something that includes unix build tools. Neither of those is trivial, nor are they cheap. But rewriting their simulator in C, as described in the article, couldn't have been cheap either.
- new299 12y ago
  Perhaps the instruction set is undocumented? (it happens). Alternative chipsets cost x10 (also happens, and is probably correlated to documentation quality). Price is an important factor, and the messy choice is often not unreasonable.
plorkyeran 12y ago
Why are you a unix shop if using Visual Studio is a hard requirement? The complexity is entirely due to you choosing tools that work poorly together, so instead pick tools that work well with the ones you can't change.
- new299 12y ago
  Seems like you're suggesting running a completely separate parallel build platform for one project. The parent seems to have taken the pragmatic, but messier choice. Sometimes, there just aren't good clean solutions, and you have to be messy and pragmatic. That, of course, is often used as an excuse for being lazy as well.
cyberpanther 12y ago
You are always going to have complexity, but we often forget to simplify before adding on more layers and tools on to our processes. I singled out Docker in particular because it is so awesome and powerful, I feel like a lot of people are just using it to cover up crappy processes. Eventually that is going to come back to haunt you in terms of slower development.

by bdamm 12y ago

fragmede 12y ago

Honestly? Port it to GCC. (Easier than LLVM, IMO) That, or switch to a different chipset, this time taking care to select something that includes unix build tools. Neither of those is trivial, nor are they cheap. But rewriting their simulator in C, as described in the article, couldn't have been cheap either.

new299 12y ago
Perhaps the instruction set is undocumented? (it happens). Alternative chipsets cost x10 (also happens, and is probably correlated to documentation quality). Price is an important factor, and the messy choice is often not unreasonable.

plorkyeran 12y ago

Why are you a unix shop if using Visual Studio is a hard requirement? The complexity is entirely due to you choosing tools that work poorly together, so instead pick tools that work well with the ones you can't change.

new299 12y ago
Seems like you're suggesting running a completely separate parallel build platform for one project. The parent seems to have taken the pragmatic, but messier choice. Sometimes, there just aren't good clean solutions, and you have to be messy and pragmatic. That, of course, is often used as an excuse for being lazy as well.

cyberpanther 12y ago

You are always going to have complexity, but we often forget to simplify before adding on more layers and tools on to our processes. I singled out Docker in particular because it is so awesome and powerful, I feel like a lot of people are just using it to cover up crappy processes. Eventually that is going to come back to haunt you in terms of slower development.