Recent

Author Topic: Unit name problem  (Read 2848 times)

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Unit name problem
« on: January 15, 2021, 10:11:11 pm »
I'm looking at applying a linkage methodology that I've used before to invoking libpython, with emphasis on still supporting Python v2 since some stuff I'm looking at is based on it (xref to my whine about Inkscape plugins, Python and Electron).

Could somebody please take a look at the attached project and explain why I'm getting "Illegal unit name" errors if DYNAMIC is defined in the main (.lpr) project file, and what I should best do about it? I'm open to constructive suggestions about how to distribute the four possibilities over directories etc.

This is using Lazarus "trunk" and FPC 3.2.0.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Unit name problem
« Reply #1 on: January 15, 2021, 10:24:41 pm »
dynamic is a procedure/function directive. if you use objfpc mode, try delphi mode, afaik it doesn't reserve directive as keywords.

Kays

  • Hero Member
  • *****
  • Posts: 569
  • Whasup!?
    • KaiBurghardt.de
Re: Unit name problem
« Reply #2 on: January 15, 2021, 10:55:13 pm »
[…] explain why I'm getting "Illegal unit name" errors […]
In PythonDemo.lpr you are using
Code: Pascal  [Select][+][-]
  1. uses
  2.   // […]
  3.   Python_dynamic in './python3/python3_dynamic'; // […]
FPC expects the unit’s name to match file (base) names, but 'python3_dynamic' <> 'Python_dynamic'. In other words, without the explicit in '…' clause you would get a unit not found error.

[…] what I should best do about it? […]
Since the files are already in different directories, just rename them and change the unit’s name (in their first line). I hope that’s it, I haven’t actually looked at your code for circumstances preventing this.
« Last Edit: January 15, 2021, 11:00:26 pm by Kays »
Yours Sincerely
Kai Burghardt

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Unit name problem
« Reply #3 on: January 15, 2021, 11:04:35 pm »
Thanks Kai, I'll check that in a few few hours.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Unit name problem
« Reply #4 on: January 15, 2021, 11:12:05 pm »
dynamic is a procedure/function directive. if you use objfpc mode, try delphi mode, afaik it doesn't reserve directive as keywords.

But that's not given problems in e.g my code at https://github.com/MarkMLl/asound which I'm using as a template. Except that in that case I'm not using the "in" clause.

I've tried several combinations of unit name (i.e. in the unit being imported), and find myself wondering whether it is some combination of "in" and "xxx_dynamic" (in the main unit)... emphasising here that "dynamic" does not appear as an isolated token so shouldn't be being recognised as one.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: Unit name problem
« Reply #5 on: January 16, 2021, 11:32:06 am »
Could somebody please take a look at the attached project and explain why I'm getting "Illegal unit name" errors if DYNAMIC is defined in the main (.lpr) project file, and what I should best do about it? I'm open to constructive suggestions about how to distribute the four possibilities over directories etc.

Would have been nice of you to provide the full error which reads as follows:

Code: [Select]
python3_dynamic.pas(1,21) Error: Illegal unit name: Python3_dynamic (expecting PYTHON_DYNAMIC)
The point is that you're using the unit as Python_dynamic in your main project file, but the unit itself is named Python3_dynamic. You need to use the unit as Python3_dynamic (you could disable this using the -Un switch, but I'm advising against that as that could lead to other troubles down the line).

dynamic is a procedure/function directive. if you use objfpc mode, try delphi mode, afaik it doesn't reserve directive as keywords.

That is completely irrelevant here, especially as the "dynamic" is part of other identifiers.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Unit name problem
« Reply #6 on: January 16, 2021, 01:14:12 pm »
The point is that you're using the unit as Python_dynamic in your main project file, but the unit itself is named Python3_dynamic. You need to use the unit as Python3_dynamic (you could disable this using the -Un switch, but I'm advising against that as that could lead to other troubles down the line).

I can assure you that I'd already tried changing that, but I am about to dive in again and will report back.

Quote
dynamic is a procedure/function directive. if you use objfpc mode, try delphi mode, afaik it doesn't reserve directive as keywords.

That is completely irrelevant here, especially as the "dynamic" is part of other identifiers.

Quite frankly I was hoping it wasn't something like that.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Unit name problem
« Reply #7 on: January 16, 2021, 03:22:30 pm »
OK, I've now gone through the files and removed the embedded version digit and it appears OK. I'm slightly puzzled: I was absolutely sure I'd tried that.

Should I assume that when I have something like

Python_dynamic in './python2/python_dynamic';

the unit name (to the left of the "in") the file name (after the path) and the unit name in the file should match, and that the only thing allowed to vary is the path (i.e. "./python2/" in the above example)?

I've got no objection at all to having the files named the same, in fact it would be my preference. But this is the first time that I've tried putting a program together with this structure covering multiple library versions, so I was being cautious.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: Unit name problem
« Reply #8 on: January 16, 2021, 05:04:14 pm »
the unit name (to the left of the "in") the file name (after the path) and the unit name in the file should match, and that the only thing allowed to vary is the path (i.e. "./python2/" in the above example)?

Correct.

Kays

  • Hero Member
  • *****
  • Posts: 569
  • Whasup!?
    • KaiBurghardt.de
Re: Unit name problem
« Reply #9 on: January 16, 2021, 05:07:42 pm »
[…] Should I assume that when I have something like
Python_dynamic in './python2/python_dynamic';
the unit name (to the left of the "in") the file name (after the path) and the unit name in the file should match, and that the only thing allowed to vary is the path (i.e. "./python2/" in the above example)? […]
Actually, the requirement is that given
Code: Pascal  [Select][+][-]
  1. uses
  2.         moduleName in 'directory/somefile.pas'
the file somefile.pas contains one
Code: Pascal  [Select][+][-]
  1. unit moduleName;
In theory it is allowed to have multiple modules in one file, although (AFAIK) FPC does not support that. The GPC allows multiple modules in one file, and many older compilers. So you’re right, using FPC all names have to correspond to each other. [And I see, PascalDragon just confirmed that.]

I think in this case it’d better to just have a couple conditional {$unitPath …} clauses to deal with multiple library versions, so the uses clause itself does not have any {$ifDef}.
Yours Sincerely
Kai Burghardt

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Unit name problem
« Reply #10 on: January 16, 2021, 05:50:29 pm »
Actually, the requirement is that given
Code: Pascal  [Select][+][-]
  1. uses
  2.         moduleName in 'directory/somefile.pas'
the file somefile.pas contains one
Code: Pascal  [Select][+][-]
  1. unit moduleName;
In theory it is allowed to have multiple modules in one file, although (AFAIK) FPC does not support that. The GPC allows multiple modules in one file, and many older compilers. So you’re right, using FPC all names have to correspond to each other. [And I see, PascalDragon just confirmed that.]

No, it doesn't like that. In the main file I've got

Code: Pascal  [Select][+][-]
  1.   python_dynamic in './python3/python3_dynamic'; (* Python is an object          *)
  2.  

and in the imported unit python3_dynamic.pas I've got

Code: Pascal  [Select][+][-]
  1. unit python_dynamic;
  2.  

and I'm now back at

Compile Project, Target: PythonDemo: Exit code 1, Errors: 1, Hints: 2
Hint: Start of reading config file /etc/fpc.cfg
Hint: End of reading config file /etc/fpc.cfg
python3_dynamic.pas(1,20) Error: Illegal unit name: python_dynamic (expecting PYTHON_DYNAMIC)


Quote
I think in this case it’d better to just have a couple conditional {$unitPath …} clauses to deal with multiple library versions, so the uses clause itself does not have any {$ifDef}.

I'm inclined to agree. In any event, I think that this does emphasise that using multiple directories is inescapable.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Unit name problem
« Reply #11 on: January 16, 2021, 06:56:33 pm »
I think in this case it’d better to just have a couple conditional {$unitPath …} clauses to deal with multiple library versions, so the uses clause itself does not have any {$ifDef}.

Unitpath is dangerous that it only activates if the module containing it is compiled, and early in the process. It works if it is in the top of your mainmodule, and exclusively compile via compiling the mainmodule.

But if you compile e.g. shared units between two programs, that might already be dangerous.


MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Unit name problem
« Reply #12 on: January 16, 2021, 07:54:16 pm »
Unitpath is dangerous that it only activates if the module containing it is compiled, and early in the process. It works if it is in the top of your mainmodule, and exclusively compile via compiling the mainmodule.

I'm afraid I've got there, and it might be worse than that. Neither with "unitpath" nor "in" are rebuilds being done reliably, I suspect that Lazarus is failing to pick up that files have been changed despite the fact that they're members of the project. In both cases "Clean Directory" followed by a build works. I hesitate to say that things are "bad" since I'm sure that I'm abusing the system in ways unintended, but I can't even rely on a rebuild if I change one of these lines in the main unit

Code: Pascal  [Select][+][-]
  1. {$define DYNAMIC }
  2. { define PYTHON2 }
  3.  

Obviously what I'm doing is more of a proof of concept than anything else, and I suspect that if I were to focus on either Python2 or Python3 and had more files in the main directory everything would be OK. But I can't simply stick everything in the same place since "in" doesn't appear to be behaving as expected.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

howardpc

  • Hero Member
  • *****
  • Posts: 4144
Re: Unit name problem
« Reply #13 on: January 16, 2021, 08:07:42 pm »
I don't know how exactly FPC handles the "in" syntax in a uses clause, but AFAIK the Lazarus IDE ignores it altogether, regarding it as a dated and flawed non-cross-platform concept of Delphi, tolerated for compatibility reasons only.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Unit name problem
« Reply #14 on: January 16, 2021, 09:03:52 pm »
I don't know how exactly FPC handles the "in" syntax in a uses clause, but AFAIK the Lazarus IDE ignores it altogether, regarding it as a dated and flawed non-cross-platform concept of Delphi, tolerated for compatibility reasons only.

"Half-heartedly" is the phrase that comes to mind :-)

The IDE has asked on a couple of occasions whether I want to add one or other of the directories to the unit path, however that's something that I specifically /don't/ want to do in the current case because of the name overlap. And the name overlap is inevitable, at least in the case of the statically-linked units, since in all cases "Python" is the interface to the underlying libraries.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

 

TinyPortal © 2005-2018