Seperate Complied code

[mahalakshmi05]

Hello Everyone, What is complied code? Why do we have to seperate it? If we seperate the compiled code and upload the project in github, will the changes done in the project after uploading be reflected in the already uploaded project or not?

[Bob_Schor]

A Web search for "Separate compiled code LabVIEW" turned up the following useful articles that should answer your question:

1. Separating Compiled Code from VIs and Other File Types 
2. Facilitating Source Code Control by Separating Compiled Code from VIs and Other File Types 
3. Separate Compiled Code from Source 

Bob Schor

[wiebe@CARYA]

---

@mahalakshmi05 wrote:

Hello Everyone, What is complied code?

---

Don't know. Compiled code is code that is compiled. The source went through a compilation process, converting it to instructions that can be executed (by a CPU or VM).

---

@mahalakshmi05 wrote:

Why do we have to seperate it?

---

You don't have to, but you might want to. Sometimes you don't want to.

---

@mahalakshmi05 wrote:

If we seperate the compiled code and upload the project in github, will the changes done in the project after uploading be reflected in the already uploaded project or not?

---

Changes will be reflected. Changes will be different, depending if SCC is on or off. 

If SCC is on, source code changes will be reflected.

If SCC is off, recompilations are also reflected.

If SCC is off, loading the source in 32 bit LabVIEW, while it was 64 bit LabVIEW, will change the files because a recompilation was needed.

If SCC is on, the compilation is still needed, but this won't change the files, and the files won't change.

[rolfk]

Your use of the SCC abbreviation is making things a little unclear now. Since one of the main reasons to enable the separation of compiled code is the use of Source Code Control, also abbreviated as SCC, the listing you provide is a bit confusing. Anybody reading that listing needs to understand that SCC in there really means "Separate Compiled Code".

[wiebe@CARYA]

---

@rolfk wrote:

Your use of the SCC abbreviation is making things a little unclear now. Since one of the main reasons to enable the separation of compiled code is the use of Source Code Control, also abbreviated as SCC, the listing you provide is a bit confusing. Anybody reading that listing needs to understand that SCC in there really means "Separate Compiled Code".

---

Ah, yes. 🌴😑 (:palmface:)

I only used SCC for "Separate Compiled Code" here.

I'll refer to Bob's suggestions. There is plenty on this online.

[JÞB]

I'll chime in (not thinking that I am THE expert computer science guy but, in more of a Bill Nye manner)

Your LabVIEW vi "Compiles " constantly.  This is what causes the "Run Arrow" to become "Broken" as you edit the VI in the Development Environment (or not! If you made a compilable change)

That VI has many parts.  Most simply, the Source Code and the Compiled Object.  The Source Code (FP, BD, ICON, Etc..) is used in the Development Environment while the Compiled Object is executed by the target processor as instructions that do things.  (Hopefully the things are useful!)

Now, LabVIEW can separate the Source code from the Compiled Object... this make some sense when you have a Source code control repository where several developers can work on the same Source Code without saving excess stuff.  All the developers have a LabVIEW development Environment so, the Compiled Objects are just "bloating" the memory needs in the SCC repository.   

We don't call it a Compiled Code Repository ( if we only want to share Compiled Code we install the Runtime Engine and an *.exe) 

So, separating Source lets each developers machine maintain its own "Cashe" of Compiled Objects while sharing the Source code that any other developer is going to automatically generate Compiled Objects from anyway.

Clear? 

With really big projects and slower speed networks that helps a lot!  When bandwidth and memory nears inf call me for a job!

[cbutcher]

For me, the key part is in Bob's second link, near the top (and expanded on further down).

Quoting incase of a future broken link:

> When you edit the source code of the VI, LabVIEW automatically recompiles the VI to reflect your changes in the compiled version of the code. LabVIEW also automatically recompiles all VIs that call the changed VI, resulting in unsaved changes to the calling VIs.

(Emphasis mine)

When you're using source code control, you typically want your changes to reflect the things you changed, and not the (non-source-code) things that LabVIEW automatically changed to make things run. 

[wiebe@CARYA]

---

@cbutcher wrote:

Quoting incase of a future broken link:

> When you edit the source code of the VI, LabVIEW automatically recompiles the VI to reflect your changes in the compiled version of the code. LabVIEW also automatically recompiles all VIs that call the changed VI, resulting in unsaved changes to the calling VIs.

---

I'm pretty sure that is not true. Sometimes callers are changed, but not always.

If a changed VI changes the callers, all caller callers should be changed (recursively). I don't see that happening. But even the direct callers do not always change.

Apparently, callers are sometimes changed because they need a recompile. If SepCC is off, the calling VI is changed. If SepCC is on, the calling VI isn't changed. 

[billko]

---

wiebe@CARYA wrote:

---

@cbutcher wrote:

Quoting incase of a future broken link:

> When you edit the source code of the VI, LabVIEW automatically recompiles the VI to reflect your changes in the compiled version of the code. LabVIEW also automatically recompiles all VIs that call the changed VI, resulting in unsaved changes to the calling VIs.

---

I'm pretty sure that is not true. Sometimes callers are changed, but not always.

If a changed VI changes the callers, all caller callers should be changed (recursively). I don't see that happening. But even the direct callers do not always change.

Apparently, callers are sometimes changed because they need a recompile. If SepCC is off, the calling VI is changed. If SepCC is on, the calling VI isn't changed. 

---

He quoted directly from the source: Facilitating Source Control by Separating Compiled Code from VIs and Other File Types 

[wiebe@CARYA]

---

@billko wrote:

---

wiebe@CARYA wrote:

---

@cbutcher wrote:

Quoting incase of a future broken link:

> When you edit the source code of the VI, LabVIEW automatically recompiles the VI to reflect your changes in the compiled version of the code. LabVIEW also automatically recompiles all VIs that call the changed VI, resulting in unsaved changes to the calling VIs.

---

I'm pretty sure that is not true. Sometimes callers are changed, but not always.

If a changed VI changes the callers, all caller callers should be changed (recursively). I don't see that happening. But even the direct callers do not always change.

Apparently, callers are sometimes changed because they need a recompile. If SepCC is off, the calling VI is changed. If SepCC is on, the calling VI isn't changed. 

---

He quoted directly from the source: Facilitating Source Control by Separating Compiled Code from VIs and Other File Types 

---

That doesn't make it true.