control the Build Order

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 Redirecting 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?

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.

Hu, code, really?

In one.pde I have

int something;

And in my other.pde I want to do

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.

Even better would be to include a statement in the appropriate pde file that says that something is defined somewhere else:

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.

I thought about that.

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

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.

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.

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.