Modules in Projects

Spire_Jeff

Is there a way to for NS4 to ONLY use the modules that are listed in the module section of the system being compiled? I just spent the better part of two hours troubleshooting a problem that may or may not be a problem because I forgot to change the module declaration statement. Only the two modules I am testing are part of the system, but they are in the same folder as the original modules. The compiler in it's infinite wisdom just found the modules in the declaration by searching, and I totally missed this (which makes it clear why everything I was trying wasn't working ).

Maybe we don't have to go so far as preventing the compiler from doing this, but maybe just add some warnings. I am thinking there should be a warning when the compiler uses a module not defined in the Modules section. There should also be a warning if there are unused module in the project. This might not be a bad idea for all of the sections.

Jeff

DHawthorne

There is a setting in the preferences where NS should look for things like include files and modules. If you remove all the entries, it should only look either in the current folder, OR wherever the module is defined to be in the workspace. It's probably giving priority to the default folders that are in there. If it can't find it in the settings, it looks where the workspace has it defined, but I have noticed lately it will sometimes ignore the workspace property in favor of a path in settings ... it didn't used to do this, and drove me batty trying to figure why older modules and includes were being used in my new compiles.

Joe Hebert

Spire_Jeff wrote:

Is there a way to for NS4 to ONLY use the modules that are listed in the module section of the system being compiled? I just spent the better part of two hours troubleshooting a problem that may or may not be a problem because I forgot to change the module declaration statement. Only the two modules I am testing are part of the system, but they are in the same folder as the original modules. The compiler in it's infinite wisdom just found the modules in the declaration by searching, and I totally missed this (which makes it clear why everything I was trying wasn't working ).

Maybe we don't have to go so far as preventing the compiler from doing this, but maybe just add some warnings. I am thinking there should be a warning when the compiler uses a module not defined in the Modules section. There should also be a warning if there are unused module in the project. This might not be a bad idea for all of the sections.

When you say modules section I assume you mean in the project workspace? Nothing is defined when you drop a module in the project. The workspace itself has nothing to do with what?s actually compiled. The compiler couldn?t care less about the files in a project workspace. The workspace is just a tool (an extremely useful tool) for us humans to organize the files used in a program, a briefcase if you will with pockets that hold all the important documents.

The compiler can only go by what?s been declared in code. You can drop dozens of modules in the project but only the ones that have been declared in code will be compiled. You can also put dozens of include files in the project but only the ones that #include in code will be compiled. You can also go the opposite route and put nothing in the workspace or not even have a project workspace at all (which drives me crazy) but if there are modules or #includes declared in code and if they can be found in the search path then they will compile.

Where it searches is a different matter and can be argued but what it actually searches for can only be determined by what?s declared in code.

I?m not against any type of suggestion for warnings to help us in our work but I do think that the only way the compiler can (and should) do its job is by what we?ve declared in code.

yuri

Joe Hebert wrote:

The compiler can only go by what?s been declared in code. You can drop dozens of modules in the project but only the ones that have been declared in code will be compiled. You can also put dozens of include files in the project but only the ones that #include in code will be compiled. You can also go the opposite route and put nothing in the workspace or not even have a project workspace at all (which drives me crazy) but if there are modules or #includes declared in code and if they can be found in the search path then they will compile.

nope, not true.
it compiles everything you put in the "Module" section of your workspace, even if it's not declared using DEFINE_MODULE.

In my case, it doenst even compile modules that are not in my "Module" workspace bit, but are declared in code using DEFINE_MODULE

Joe Hebert

yuri wrote:

nope, not true.
it compiles everything you put in the "Module" section of your workspace, even if it's not declared using DEFINE_MODULE.

If you do a build all it will compile everything but not as part of the program.

yuri wrote:

In my case, it doenst even compile modules that are not in my "Module" workspace bit, but are declared in code using DEFINE_MODULE

Nope, not true in my case. I can use a module that's not in my workspace. If you needed a workspace then a command line compiler wouldn't work. Would it?

yuri

i always use "compile active system".
i don't know the command line compiler parameters, but i'm guessing you have to pass a reference to the modules you are using...

Joe Hebert

yuri wrote:

i always use "compile active system".
i don't know the command line compiler parameters, but i'm guessing you have to pass a reference to the modules you are using...

My only point is that it doesn?t matter what?s in your workspace. You can have all the modules you want in your project but the only modules that will be compiled into your program are the ones you declare. And furthermore you can have modules compiled into your program that are not in the project workspace as Jeff experienced first hand. The workspace is just an organizational tool.

I usually use ?compile as Netlinx? because it takes less time. If I?m working on a module then I ?compile as Nelinx.? If I?m working on the main program then I also do a ?compile as Netlinx? because ?build active system? just recompiles what?s already been compiled before (assuming the .axs version of the module is in your project) Once there is a .tko for a module there is no need to recompile the module unless you are changing the module. The .output from a module (the .tko) gets linked into the final product (the .tkn) if the module is declared in the program.

That's my story and I'm sticking to it.

yuri

Joe Hebert wrote:

...

i'm not saying you aren't right. I'm just saying my output window tells something else (for me )

vining

Joe Hebert wrote:

I usually use ?compile as Netlinx? because it takes less time. If I?m working on a module then I ?compile as Nelinx.? ......

Same here. Actually I never use "compile active system".

ericmedley

I only use 'Build Active System' I think it's just good house keeping really. All its doing is compiling, saving all docs, and organizing the project links and references. (things like device mapping, etc...) I think it's more important with Duet stuff.

[Deleted User]

Compile or !compile, that is the question.

Joe Hebert wrote:

I usually use ?compile as Netlinx? because it takes less time. If I?m working on a module then I ?compile as Nelinx.? If I?m working on the main program then I also do a ?compile as Netlinx? because ?build active system? just recompiles what?s already been compiled before (assuming the .axs version of the module is in your project) Once there is a .tko for a module there is no need to recompile the module unless you are changing the module. The .output from a module (the .tko) gets linked into the final product (the .tkn) if the module is declared in the program.

I'm with Joe on this one...compile only what you need to compile.

Not only does it take more time, needless recompiling of unchanged modules continues to reset the date of the .tko file. If the module has not changed, why recompile it? In fact, I typically add only the .tko file of any module to my workspace unless I intend to edit the source file.

Spire_Jeff

Joe Hebert wrote:

When you say modules section I assume you mean in the project workspace? Nothing is defined when you drop a module in the project. The workspace itself has nothing to do with what?s actually compiled. The compiler couldn?t care less about the files in a project workspace. The workspace is just a tool (an extremely useful tool) for us humans to organize the files used in a program, a briefcase if you will with pockets that hold all the important documents.

The compiler can only go by what?s been declared in code. You can drop dozens of modules in the project but only the ones that have been declared in code will be compiled. You can also put dozens of include files in the project but only the ones that #include in code will be compiled. You can also go the opposite route and put nothing in the workspace or not even have a project workspace at all (which drives me crazy) but if there are modules or #includes declared in code and if they can be found in the search path then they will compile.

I apologize for being unclear. I don't want the compiler to automatically add a module to the code when I place it into the workspace. After some thought, I think the best way to handle this is for a warning to be sent when a module/include is used and it is not part of the workspace. I would also like it if the compiler gave warnings for includes/modules that are defined in the workspace, but not in code. Because they would be warnings, it would not prevent the compiler from compiling, but it would alert me (yes, it's all about me ) as to what the compiler is doing.

Even if this can't be done during the compile process, maybe they could add a project report that scans the active code and lists any files in the workspace that aren't being used. It could also list all of the includes and modules that are being used along with their path.

I believe that a file export already does some of this reporting, so it should be feasible.

Jeff

[Deleted User]

Order of things...

A little insight on how the NetLinx compilation process actually works within NS2:

1) Selecting to "Build System" will compile and link ALL the AXS files that are part of the MODULE and SOURCE folders within the SYSTEM.

2) Selecting to "Compile as NetLinx" will only compile the AXS file that is currently in focus within the editor. Or if you have right-mouse clicked on a file within the workspace, you can compile only that selected AXS file.

3) The following is the look-up order that the compiler uses to find your defined modules during the link phase:
1 - Path of the "Master" AXS file as defined within your SYSTEM.
2 - All paths that are found from the AXS files that are part of your MODULE and SOURCE folders of SYSTEM.
3 - Directory definitions found under "Module Files" located on the NetLinx Compiler tab within the "Preferences" dialog.

4) Same order applies above when the compiler needs to find your "Include" files, with the "Include Files" directories definitions being used in step 3 above instead of the "Module Files" directories.

If you have a SYSTEM with 200 modules, but your Main program only requires 3 modules to link, all 200 modules will compile, but the resulting TKN will only contain the byte-code for the 3 required modules (i.e. the TKN will not be bloated with unneeded module code).

Hope this helps...or maybe it adds to the confusion...:)

Spire_Jeff

dvalosek wrote:

3) The following is the look-up order that the compiler uses to find your defined modules during the link phase:
1 - Path of the "Master" AXS file as defined within your SYSTEM.
2 - All paths that are found from the AXS files that are part of your MODULE and SOURCE folders of SYSTEM.
3 - Directory definitions found under "Module Files" located on the NetLinx Compiler tab within the "Preferences" dialog.

This has caused me problems in the past. I couple times, copies of the module got placed into the path of the Master AXS file. It drove me up a wall not knowing why the changes I was making to the modules wasn't having any effect.

Thank you for posting this, because at least I now have some understanding of how things are handled.

Jeff

DHawthorne

I think the look-up order is broken, or has been changed. It has always been my habit to have a "boilerplate" include file for certain modules in main projects folder. Each individual project has a sub folder off that, with a local copy customized for the job. This has always worked just fine until recently; but I started noticing a while ago that it was using the include from the main folder, even though there was a local copy in the folder the project was in, and the local was the include defined in the workspace. I have had to go back and start renaming my boilerplates so they would not be used. That folder is part named in preferences, and has obviously been the first place the compiler is looking, not the third. This is for includes; I haven't tested for modules since I generally don't have local copies of modules, they reside permanently in that folder anyway.

I can't tell you when I started noticing this; I would think it had to be introduced with October's update of NS.

ericmedley

DHawthorne wrote:

I think the look-up order is broken, or has been changed. It has always been my habit to have a "boilerplate" include file for certain modules in main projects folder. Each individual project has a sub folder off that, with a local copy customized for the job. This has always worked just fine until recently; but I started noticing a while ago that it was using the include from the main folder, even though there was a local copy in the folder the project was in, and the local was the include defined in the workspace. I have had to go back and start renaming my boilerplates so they would not be used. That folder is part named in preferences, and has obviously been the first place the compiler is looking, not the third. This is for includes; I haven't tested for modules since I generally don't have local copies of modules, they reside permanently in that folder anyway.

I can't tell you when I started noticing this; I would think it had to be introduced with October's update of NS.

That's interesting. I tend to keep all files in the client's project folder. I also have several sub-folders in the project folder I label myself. (Includes, IR_Files, Modules, Manuals, Documents, etc...) I track what you'd call boilerplate stuff by its version number. I quite often have several versions of something depending upon what's at their system.

The reason for doing this is that I want no question about where any given file for a project is located. So, If a tech is running out with a project, all the files are in that folder, no questions. Granted I have multiple copies of the same file all over the place. but, what the heck... Hard drives are cheap.

In our case we tend to have more than one person working on stuff at a time. I store all our projects on a server and we run it 'production-style' In other words, the working projects are always stored on the server and I don't allow anyone to copy to their desktop and work locally. Our network is fast enough that it is never an issue. Our server is backed up each day and I also make a 2nd backup to an outside server. The only occasion that anyone would really need to copy it to a laptop is when they might be going somewhere where the internet is not running yet (new install) Otherwise, we try to use remote login and run from machines here.

It has saved our keisters more than once.

Jimweir192

I agree Dave, something has changed with the lookup for modules - sometime in the last 3 months - the way I work with files & storage has not changed, but everytime I revisit an old project I seem to do battle with the modules if I have to make any changes...

The workspace hasn't been changed - nor the file storage, but often any minor change to a module is ignored and the old module is reused... Regardless of which way the rev module is compiled. This nearly drove me bonkers yesterday - again...

Is anyone else having these issues?