Pages: [1]   Go Down
Author Topic: control the Build Order  (Read 638 times)
0 Members and 1 Guest are viewing this topic.
0
Offline Offline
Newbie
*
Karma: 1
Posts: 41
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

To make my project more structured I try to divide the parts into multiple TABs inside the Arduino IDE. Current decision is to use a multi file sketch with no extension (so files have the .pde extension).

According to http://www.arduino.cc/en/Hacking/BuildProcess these sketches are concatenated together.

I have problems with variable declarations needed in earlier parts that are merged as later parts (making the compiler unhappy).

I don't really want to switch to .h/.c stuff. Do I have any chance to control the order of this merge process?

Logged

Seattle, WA USA
Offline Offline
Brattain Member
*****
Karma: 551
Posts: 46240
Seattle, WA USA
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
I have problems with variable declarations needed in earlier parts that are merged as later parts (making the compiler unhappy).
There is probably no one-size-fits-all answer. Posting some code and error messages will be necessary to solve your issue.
Logged

0
Offline Offline
Newbie
*
Karma: 1
Posts: 41
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hu, code, really?

In one.pde I have
Code:
int something;

And in my other.pde I want to do
Code:
void nana() {
  something++;
}

THis compiles, if  one.pde is merged in front of other.pde. It does not compile, if other.pde is merged in front of one.pde.

I don't want to change the code, I want to control the order or merging.

Addendum: it looks like the merge order is the same as the order of the open tabs. And the open tabs are ordered alphabetically. So I will change my filenames to meet the order I need.
« Last Edit: December 14, 2010, 10:57:21 am by hole » Logged

Seattle, WA USA
Offline Offline
Brattain Member
*****
Karma: 551
Posts: 46240
Seattle, WA USA
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Even better would be to include a statement in the appropriate pde file that says that something is defined somewhere else:
Code:
extern int something;
This tells the current sketch that something is an int, and the the actual space for it is reserved somewhere else.

Then, the order of compiling doesn't matter.
Logged

0
Offline Offline
Newbie
*
Karma: 1
Posts: 41
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I thought about that.

But than I have to edit at two (or even more) locations, if I change something.
Logged

Seattle, WA USA
Offline Offline
Brattain Member
*****
Karma: 551
Posts: 46240
Seattle, WA USA
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
But than I have to edit at two (or even more) locations, if I change something.
Then, you really should be using a header file.
Logged

0
Offline Offline
Newbie
*
Karma: 1
Posts: 41
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I know.

Problem (or challenge) is to keep the requirements at a low level. It's an educational project and the students have almost no knowledge about anything.

And adding multiple file types into the game shall be the next step. Currently we are busy with understanding why we need to spilt things in reusable parts and how to design it in a resuable way.
« Last Edit: December 14, 2010, 02:01:49 pm by hole » Logged

Seattle, WA USA
Offline Offline
Brattain Member
*****
Karma: 551
Posts: 46240
Seattle, WA USA
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I think I'd want to introduce header files as a means of corralling data that will need to be shared before introducing the mechanism for sharing. I say this because it's easier to continue doing something that works instead of unlearning that and learning to do it the right way.

Naming files to define the compile order is fraught with peril. Not everyone can speel wel, and mispelings defnng compiler order doesn't feel write.
Logged

Pages: [1]   Go Up
Jump to: