v5.30: Compiler refuses to compile a sourcefile [OK]

[Dany]

Hi,

Something odd:

The compiler refuses to compile an .mpas file of which the source file is in the project manager under "sources", also after a change of the file content. The project continous to use the (old) .mcl file apparently.
The option "always build all files in project" is on.

The compilation (yes or no) of that particular file depends on whether (yes or no) the source file of an installed library (in the library manager) is present (the .mcl file is always present). Very odd.


The project at hand:
In the attachment the full project is found, except for the packages installed.

- Two packages are used in the project:
USB_OA: see http://www.rosseeld.be/DRO/PIC/USB_OA.mpkg
Utilities: see http://www.rosseeld.be/DRO/PIC/Utilities.mpkg

- All files in the zipfile are present in the working directory "C:\PIC Projects PRO compiler\Prototyping\USB\USB Test of Own CDC Library", the 2 installed packages are present in the standard package locations.

The problem:
- The source file "USB_CDC_ProjectItems.mpas" will not be compiled if the library source file "USB_CDC_Library.mpas" is absent (remove or rename this file in the packages "uses" directory).
The library uses some constants defined in the "USB_CDC_ProjectItems.mpas" file.

The logfile:

0 1 mPPic.exe -MSF -DBG -pP18F2550 -Y -DL -RA -O11111114 -fo48 -N"C:\PIC Projects PRO compiler\Prototyping\USB\USB Test of Own CDC Library\USB_CDC_Demo.mpppi" -SP"C:\Users\Public\Documents\Mikroelektronika\mikroPascal PRO for PIC\Defs\" -SP"C:\Users\Public\Documents\Mikroelektronika\mikroPascal PRO for PIC\uses\P18\" -SP"C:\PIC Projects PRO compiler\Prototyping\USB\USB Test of Own CDC Library\" -SP"C:\Users\Public\Documents\Mikroelektronika\mikroPascal PRO for PIC\Packages\USB_OA\Uses\" -SP"C:\Users\Public\Documents\Mikroelektronika\mikroPascal PRO for PIC\Packages\Utilities\Uses\" "__Lib_Math.mcl" "__Lib_MathDouble.mcl" "__Lib_System.mcl" "__Lib_Delays.mcl" "__Lib_String.mcl" "__Lib_Conversions.mcl" "__Lib_SoftUART.mcl" "__Lib_UART_c67.mcl" "USB_CDC_Library.mcl" "BitUtils.mcl" "USB_CDC_Demo.mpas" "USB_CDC_ProjectItems.mpas" "USB_CDC_Demo.pld"
diagnostics: 0 155 Available RAM: 2027 [bytes], Available ROM: 32768 [bytes]
diagnostics: 0 133 Compilation Started C:\Users\Public\Documents\Mikroelektronika\mikroPascal PRO for PIC\defs\P18F2550.mpas
hint: 1 1015 Hint: Compiling unit "C:\Users\Public\Documents\Mikroelektronika\mikroPascal PRO for PIC\defs\P18F2550.mpas" P18F2550.mpas
hint: 1413 1010 Hint: Unit "P18F2550.mpas" has been recompiled P18F2550.mpas
diagnostics: 0 134 Compiled Successfully C:\Users\Public\Documents\Mikroelektronika\mikroPascal PRO for PIC\defs\P18F2550.mpas
diagnostics: 0 133 Compilation Started C:\Users\Public\Documents\Mikroelektronika\mikroPascal PRO for PIC\uses\P18\__Lib_Delays.mpas
hint: 1 1015 Hint: Compiling unit "C:\Users\Public\Documents\Mikroelektronika\mikroPascal PRO for PIC\uses\P18\__Lib_Delays.mpas" __Lib_Delays.mpas
hint: 188 1010 Hint: Unit "__Lib_Delays.mpas" has been recompiled __Lib_Delays.mpas
diagnostics: 0 134 Compiled Successfully C:\Users\Public\Documents\Mikroelektronika\mikroPascal PRO for PIC\uses\P18\__Lib_Delays.mpas
diagnostics: 0 133 Compilation Started C:\Users\Public\Documents\Mikroelektronika\mikroPascal PRO for PIC\Packages\Utilities\Uses\BitUtils.mpas
hint: 1 1015 Hint: Compiling unit "C:\Users\Public\Documents\Mikroelektronika\mikroPascal PRO for PIC\Packages\Utilities\Uses\BitUtils.mpas" BitUtils.mpas
hint: 199 1011 Hint: Variable "BitNr" has been eliminated by optimizer BitUtils.mpas
hint: 213 1011 Hint: Variable "ByteNr" has been eliminated by optimizer BitUtils.mpas
hint: 213 1011 Hint: Variable "BitNr" has been eliminated by optimizer BitUtils.mpas
hint: 213 1011 Hint: Variable "Mask" has been eliminated by optimizer BitUtils.mpas
hint: 239 1011 Hint: Variable "BitNr" has been eliminated by optimizer BitUtils.mpas
hint: 253 1011 Hint: Variable "ByteNr" has been eliminated by optimizer BitUtils.mpas
hint: 253 1011 Hint: Variable "BitNr" has been eliminated by optimizer BitUtils.mpas
hint: 253 1011 Hint: Variable "Mask" has been eliminated by optimizer BitUtils.mpas
hint: 261 1010 Hint: Unit "BitUtils.mpas" has been recompiled BitUtils.mpas
diagnostics: 0 134 Compiled Successfully C:\Users\Public\Documents\Mikroelektronika\mikroPascal PRO for PIC\Packages\Utilities\Uses\BitUtils.mpas
diagnostics: 0 133 Compilation Started C:\PIC Projects PRO compiler\Prototyping\USB\USB Test of Own CDC Library\USB_CDC_Demo.mpas
hint: 1 1015 Hint: Compiling unit "C:\PIC Projects PRO compiler\Prototyping\USB\USB Test of Own CDC Library\USB_CDC_Demo.mpas" USB_CDC_Demo.mpas
hint: 50 1021 Hint: interrupt handler (interrupt at 0x0008) USB_CDC_Demo.mpas
hint: 67 1011 Hint: Variable "Recvd" has been eliminated by optimizer USB_CDC_Demo.mpas
hint: 180 1010 Hint: Unit "USB_CDC_Demo.mpas" has been recompiled USB_CDC_Demo.mpas
diagnostics: 0 134 Compiled Successfully C:\PIC Projects PRO compiler\Prototyping\USB\USB Test of Own CDC Library\USB_CDC_Demo.mpas
diagnostics: 0 139 All files Compiled in 0 ms
hint: 0 1144 Used RAM (bytes): 680 (34%) Free RAM (bytes): 1347 (66%) Used RAM (bytes): 680 (34%) Free RAM (bytes): 1347 (66%)
hint: 0 1144 Used ROM (bytes): 4366 (13%) Free ROM (bytes): 28402 (87%) Used ROM (bytes): 4366 (13%) Free ROM (bytes): 28402 (87%)
diagnostics: 0 145 Project Linked Successfully USB_CDC_Demo.mpppi
diagnostics: 0 140 Linked in 63 ms
diagnostics: 0 141 Project 'USB_CDC_Demo.mpppi' completed: 172 ms
diagnostics: 0 103 Finished successfully: 05 dec 2011, 20:03:19 USB_CDC_Demo.mpppi

As you can see the file "USB_CDC_ProjectItems.mpas" is in the command line, but is further not mentioned in the logfile (no compilation done).

Thanks in advance!

[janko.kaljevic]

Hello,

Please can you upload your packages again (it looks like they are missing).
We are not able to reproduce this behavior.

Best regards.

[Dany]

Hello,

Please can you upload your packages again (it looks like they are missing).
We are not able to reproduce this behavior.

Best regards.

So sorry, the LibStock links I gave in the first post were wrong. Here are the correct ones:

USB_OA: see http://www.rosseeld.be/DRO/PIC/USB_OA.mpkg
Utilities: see http://www.rosseeld.be/DRO/PIC/Utilities.mpkg

Sorry.

[Dany]

Any news?

[janko.kaljevic]

Hello,

I have tested this and failed to reproduced.

When "always build all files in project" is on, project compiles every time without problems.
Is there anything more that I need to do in order to recreate this behavior?

Best regards.

[Dany]

I have tested this and failed to reproduced.

That is a pity. I will try to find a method to reproduce it.

When "always build all files in project" is on, project compiles every time without problems.

I always have "always build all files in project" set to on. Even then the compiler does not compile some sourcefiles apparently (I know it sounds impossible...)

Is there anything more that I need to do in order to recreate this behavior?

I will try to find a method to reproduce it...

Thanks for the effort!!

[Dany]

Is there anything more that I need to do in order to recreate this behavior?

Well, the only thing I had to do to reproduce the phenomenon is renaming the library source file "USB_CDC_Library.mpas" to something else, while leaving the .mcl file as it was.

[janko.kaljevic]

Hello,

Actually I have done that too (deleted that file), and still everything works on my system.

I can not find way to reproduce this behavior.

Best regards.

[Dany]

Hello,
Actually I have done that too (deleted that file), and still everything works on my system.
I can not find way to reproduce this behavior.
Best regards.

Ok, I will try to find a way to reporduce. Thanks anyway!

[Dany]

Hi, I have a very simple project in which I can reproduce the phenomenon, see attachment. It seems it could be related to libraries in a package.

*The project contains 2 sourcefiles:
-TestCompiling (the main file)
-UnitOne, which only contains a constant definition.

*The project uses a library called MyLib, which is installed as a package, in "C:\Users\Public\Documents\Mikroelektronika\mikroPascal PRO for PIC\Packages\Utilities\Uses" (windows7 directory).
As you can see, the name of the package is "Utilities". This was an existing package for me, I only added the MyLib files to it. Any package name will do however, provideing it is in the package inifile (in C:\Users\Public\Documents\Mikroelektronika\mikroPascal PRO for PIC\Packages).

Important: This library uses the constant defined in "UnitOne", so it contains the "Uses UnitOne" statement.


*If all goes well, then running the program will copy the value of "abc" (UnitOne) into xyz (TestCompiling), so this is the test to perform.

Now, as long as the MyLib.mpas file is present in the installed package (C:\Users\Public\Documents\Mikroelektronika\mikroPascal PRO for PIC\Packages\Utilities\Uses), all goes well.

However, if only the MyLib.mcl file is present in "C:\Users\Public\Documents\Mikroelektronika\mikroPascal PRO for PIC\Packages\Utilities\Uses", the file "UnitOne" is not compiled anymore, even if it was edited!! Of course xyz gets an "old" (not the one defined in UnitOne) value now!


*The zipfile contains the project files and the library Mylib .mpas and .mcl file.
Additionally I have added the P18F2550.mlk file, where all libraries for the 18f2550 are defined.

Thanks in advance!

[janni]

However, if only the MyLib.mcl file is present in "C:\Users\Public\Documents\Mikroelektronika\mikroPascal PRO for PIC\Packages\Utilities\Uses", the file "UnitOne" is not compiled anymore, even if it was edited!!

That's because it's not used by any part of the project that can be compiled. (If it was, it would be compiled but it still would not lead to updating the constant in your lib file as mcl file cannot be recompiled.)

[Dany]

Thanks janni.

However, if only the MyLib.mcl file is present in "C:\Users\Public\Documents\Mikroelektronika\mikroPascal PRO for PIC\Packages\Utilities\Uses", the file "UnitOne" is not compiled anymore, even if it was edited!!

That's because it's not used by any part of the project that can be compiled.

Still, the options are set to "build all sourcefiles" (and normally all are compiled in such case, even if they are not part of the project).
Even more: if the library is not used in the main program (no uses clause, no call to its routine), then the unit "UnitOne" is only compiled if the library is unchecked in the library manager. Checking the (unused by the project) library already prevents compilation of "UnitOne". Odd.

(If it was, it would be compiled but it still would not lead to updating the constant in your lib file as mcl file cannot be recompiled.)

Yes, that is another problem, see http://www.mikroe.com/forum/viewtopic.php?f=86&t=32217.
Indeed, if I leave out the "uses UnitOne" clause in "MyLib" and replace it there with an "external" declaration of the constant then the "UnitOne" is always compiled...

So, for both problems the solution is to use external declarations...
Still a very odd phenomenon, the non compilation of a file while "build all sources" is on and the source of a user lib in a package is absent...

[janni]

Still, the options are set to "build all sourcefiles" (and normally all are compiled in such case, even if they are not part of the project).
Even more: if the library is not used in the main program (no uses clause, no call to its routine), then the unit "UnitOne" is only compiled if the library is unchecked in the library manager. Checking the (unused by the project) library already prevents compilation of "UnitOne". Odd.

Well, I'd say it's the only solution. If UnitOne was compiled when the library is used, it'd suggest that the lib was updated or worse - state of the lib and it's source unit (UnitOne) would not be compatible. The 'build all sourcefiles' option, on the other hand, allows to compile disconnected source files which is sometimes handy but not always purposeful.

There are two other choices - to use the 'build all sourcefiles' option only when necessary (sources connected with the opened project(s) are supposed to be compiled even without this option - unless they're unchanged), or, as Janko suggested in the other thread, an error stating that source file is needed for build will be raised whenever there's only mcl file using an opened source file. This will naturally make viewing in IDE of a source file used by a precompiled lib impossible, making lib designer's life hard (for example, viewing a header file with some constants declarations to recall what a lib uses will prevent project compilation).

Personally, I don't like the latter solution . Maybe a warning would be a compromise?

[Dany]

Still, the options are set to "build all sourcefiles" (and normally all are compiled in such case, even if they are not part of the project).
Even more: if the library is not used in the main program (no uses clause, no call to its routine), then the unit "UnitOne" is only compiled if the library is unchecked in the library manager. Checking the (unused by the project) library already prevents compilation of "UnitOne". Odd.

Well, I'd say it's the only solution. If UnitOne was compiled when the library is used, it'd suggest that the lib was updated or worse - state of the lib and it's source unit (UnitOne) would not be compatible. The 'build all sourcefiles' option, on the other hand, allows to compile disconnected source files which is sometimes handy but not always purposeful.

There are two other choices - to use the 'build all sourcefiles' option only when necessary (sources connected with the opened project(s) are supposed to be compiled even without this option - unless they're unchanged), or, as Janko suggested in the other thread, an error stating that source file is needed for build will be raised whenever there's only mcl file using an opened source file. This will naturally make viewing in IDE of a source file used by a precompiled lib impossible, making lib designer's life hard (for example, viewing a header file with some constants declarations to recall what a lib uses will prevent project compilation).

Personally, I don't like the latter solution . Maybe a warning would be a compromise?

Thanks Janni.

Personally I would not change anything at all with respect to the compiler and/or linker. The mechanism is know now to me, and I can live perfectly with it as it is. I will make the necessary arrangements in my libraries to make them compliant.

p.s. I would be a good thing if an article would describe the whole compiling and linking process, including "external" definitions, "uses" clauses, the project manager, the library manager, the .mpppi file content, do's and dont's in user libraries.

Thanks everyone!