Hi

Graphics32 nowadays supports Lazarus and has Lazarus packages for design- and run-time.
There is something fuzzy in Lazarus package system.

The design-time package "GR32_DSGN_Lazarus" has dependency for the run-time package "GR32_Lazarus", which is correct IMO. Yet, during installing "GR32_DSGN_Lazarus" and recompiling Lazarus, it says : ---
Unable to find file "GR32_Blend.pas".
If it belongs to your project, check search path in Project -> Compiler Options -> Search Paths -> Other Unit Files. If this file belongs to a package, check the appropriate package compiler options. If this file belongs to lazarus, make sure compiling clean. If the file belongs to FPC then check fpc.cfg. If unsure, check Project -> CompilerOptions -> Test
---

"GR32_Blend.pas" is part of the run-time package and can be found easily. Codetools find it, too.
It is possible to install the design-time package only after compiling the run-time package manually. It should not be needed because the dependency is set correctly.
The problem comes back every time you do a clean build for Lazarus, or remove .ppu files for other reasons.

Tested with Graphics32 release 1.9.1 and trunk,
using Lazarus trunk on Windows and Linux+GTK2.

To test it, first load Graphics32 :
$ svn co https://graphics32.svn.sourceforge.net/svnroot/graphics32/trunk graphics32_trunk

Then try to install
Source/Packages/GR32_DSGN_Lazarus.lpk

I would say this is a bug in Lazarus.
First I thought the problem was in their package. I figured I solved it and I sent a patch to
http://sourceforge.net/tracker/?func=detail&aid=3599094&group_id=112985&atid=663799

but finally it makes no difference. I copy it below just for reference.

Regards,
Juha

---
--- GR32_DSGN_Lazarus.lpk (revision 2123)
+++ GR32_DSGN_Lazarus.lpk (working copy)
@@ -7,7 +7,7 @@
<Version Value="11"/>
<SearchPaths>
<IncludeFiles Value=".."/>
- <OtherUnitFiles Value="..;../Packages"/>
+ <OtherUnitFiles Value=".."/>
<UnitOutputDirectory
Value="lib/$(TargetCPU)-$(TargetOS)/$(LCLWidgetType)"/> </SearchPaths>
<Parsing>
@@ -71,7 +71,7 @@
<UnitName Value="GR32_Dsgn_Bitmap"/>
</Item5>
</Files>
- <Type Value="DesignTime"/>
+ <Type Value="RunAndDesignTime"/>
<RequiredPkgs Count="3">
<Item1>
<PackageName Value="GR32_Lazarus"/>

Does anybody use the Graphics32 library?
How does it compare with the other graph libraries for Lazarus? The project is alive for sure but not very active. For example nobody yet commented my patch in any ways.

I am (again) experimenting with porting the DeleD 3-D design app for Lazarus. http://www.delgine.com/

The problem is that I don't know OpenGL or other graphics programming well but I must learn some.

Regards,
Juha

Codetools do not care if a file is reachable multiple times. fpc does, because of its ppu files.
Make sure both packages do not share any source directory.

What exactly is the bug?

Mattias

Mattias Gaertner wrote

Codetools do not care if a file is reachable multiple times. fpc does, because of its ppu files. Make sure both packages do not share any source directory.

They share the source directory but not any source files. The package .lpk files are in "Packages" directory below the source directory. I thought it is allowed. Is it not?

What exactly is the bug?

If the rule is against sharing source directories between packages, then it is a feature, not a bug.
I am still wondering why such rule is needed.

Juha

Are you sure? The error indicates that they share unit GR32_Blend.

The package .lpk files are in "Packages" directory below the source directory. I thought it is allowed. Is it not?

You can put the lpk where ever you want.

First of all:
The rule is only a recommendation, it is not forced by the IDE. There are cases where it makes sense to share a directory (e.g. historical reasons, other build systems). The IDE should detect such things and warn.

Two packages are compiled with different sets of
options, so fpc might recompile the shared unit, which means all depending units must be recompiled as well, creating a logical circle. If you can not split the sources of the two lpk and both lpk should always be compiled exactly the same, then it is probably easier to merge the two lpk into one.

Mattias

I am sure. I copy the .lpk files here.
You can also verify it by using the SVN link from my earlier mail. Can the problem be in FPC 2.6.0 which I am using now?

Juha
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GR32_DSGN_Lazarus.lpk
Type: application/octet-stream
Size: 3993 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130105/f940d2b4/attachment.obj> -------------- next part --------------
A non-text attachment was scrubbed...
Name: GR32_Lazarus.lpk
Type: application/octet-stream
Size: 5979 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130105/f940d2b4/attachment-0001.obj>

[...] To test it, first load Graphics32 : $ svn co https://graphics32.svn.sourceforge.net/svnroot/graphics32/trunk graphics32_trunk

I took a brief look.
- GR32_Lazarus is marked as runtime package but depends on IDEIntf. It seems this is not needed.
- Both packages use the same unit output directory.

This should work. Although I would recommend to
separate the design units.

Then try to install Source/Packages/GR32_DSGN_Lazarus.lpk

It fails, because fpc recompiles some units of the runtime package when compiling the design time package. I don't know why it recompiles. Maybe because of the inlines and the many unit cycles. This bug exists in FPC since several years.

Mattias

I finally decided to make it a single package.
I uninstalled both from Lazarus, deleted all *.ppu and *.o under graphics32_trunk, and built Lazarus clean.

Then I added the design units (the ones from GR32_DSGN_Lazarus.lpk) into GR32_Lazarus.lpk and changed its IDE Integration to "Designtime and runtime".
Then I installed and ... again it fails for the same reason. I give up. I remember there were lots of similar problems with packages earlier but they were fixed by Mattias.
This one bothers me because I can't find the reason. I experimented with the settings, I also renamed the old design time package so it didn't interfere.
The problem is in the settings or paths of one package.

Juha

The paths are pretty simple. One "..". The settings are common too. Mode Delphi, O1, intel assembler mode. So, no problem here.

FPC requires three compiles to build the package due to the many unit cycles.
Sort the uses sections. Put gr32 units at the end. Try to move as many units from the implementation sections to the interface sections.
Finally: refactor and break the cycles.

Mattias