Recent

Author Topic: Unit name problem  (Read 2849 times)

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Unit name problem
« Reply #15 on: January 16, 2021, 09:33:56 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,

The documentation of unitpath says it is local to the current module only. But it doesn't say what relative paths are expanded against. I filed a bug for that 

Quote
I suspect that Lazarus is failing to pick up that files have been changed despite the fact that they're members of the project.

FPC only sees cmdline parameters and what is in the .lpr.  (and to be complete .cfgs and environment variables, but that is fairly not often the cause of problems)

Quote
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

I don't know how   xxx in  'yyy' is processed, and if this matters for later references to xxx.

If some references have paths, and others not or different, that could cause problems. Since if a second reference is encountered, but the first one was not found (e.g. because that unit wasn't changed and thus not recompiled), the compiler couldn't know about it, even theoretically.

The documentation  for the feature is again very sketchy.

« Last Edit: January 16, 2021, 10:18:26 pm by marcov »

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Unit name problem
« Reply #16 on: January 16, 2021, 10:30:44 pm »
The documentation of unitpath says it is local to the current module only. But it doesn't say what relative paths are expanded against. I filed a bug for that 

Thanks for that, your opinion carries more weight than mine.

Quote
FPC only sees cmdline parameters and what is in the .lpr.  (and to be complete .cfgs and environment variables, but that is fairly not often the cause of problems)

Well, /something/ appears to not be being picked up if only the $define directives in the main unit are changed, which is odd. And their effect is strictly local, i.e. they're in the main unit rather than the lpi/lps and there isn't an include file in that unit.

Quote
I don't know how   xxx in  'yyy' is processed, and if this matters for later references to xxx.

If some references have paths, and others not or different, that could cause problems. Since if a second reference is encountered, but the first one was not found (e.g. because that unit wasn't changed and thus not recompiled), the compiler couldn't know about it, even theoretically.

The documentation  for the feature is again very sketchy.

I suspect there's been a regression. I'm currently copying older projects into my Python v2 interface and will then try v3, so I'd rather not work on test cases right now.

(Thinks to self): this is something I've done several times by now, starting off with some MIDI stuff years ago. The description of both the statically- and dynamically-linked libraries is going into a common include file, and in principle the units that make use of it could be generated automatically.

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 #17 on: January 19, 2021, 06:11:07 pm »
(Thinks to self): this is something I've done several times by now, starting off with some MIDI stuff years ago. The description of both the statically- and dynamically-linked libraries is going into a common include file, and in principle the units that make use of it could be generated automatically.

I thought an update might possibly be of interest, or at least worth getting "into the record".

Using a fairly natural format, it's possible to put library definitions into an include file in such a way that they're useful both when a library is being "consumed" but also when it's being created (this is something I've been doing for years, but it tends to be hard work). Descriptive comments placed in this are picked up by the Lazarus IDE as hover-over declaration hints.

I now have a program which will parse this file, and generate unit files for both static and dynamic linkage (i.e. interfaces to libsomething.a and libsomething.so respectively). These still need a bit of fettling, e.g. to fill in local functions which replace C macros, but for a moderate-sized library this replaces thousands of lines of systematic edits.

Using this, I can now embed a simple Python v2 script using either static or dynamic linking. Extending this to v3 should not be particularly difficult.

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 #18 on: February 11, 2021, 09:37:29 am »
FPC 3.2.0 doesn't automatically compile units which should be reached via the unitpath directive.

Is this as intended?

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 #19 on: February 11, 2021, 11:57:25 am »
FPC 3.2.0 doesn't automatically compile units which should be reached via the unitpath directive.

Is this as intended?

I checked and $unitpath is expanded relative to the path of the source module it is in. (so a $unitpath in a $I'd  file will lead to various expansions depending on which unit imports it).

Check with -va what it compiles.

(earlier comments based on that $unitpath was not local removed, it is local per documentation and also seems local to the source it is in in the compiler sources)
« Last Edit: February 11, 2021, 12:00:30 pm by marcov »

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Unit name problem
« Reply #20 on: February 11, 2021, 02:54:22 pm »
FPC 3.2.0 doesn't automatically compile units which should be reached via the unitpath directive.

Is this as intended?

Check with -va what it compiles.

It's gone again. It's a Heisenbug.

Dagnabbit: I was pretty sure I'd got something reproducible that time. Bet it only happens if the locale is set so that the current day has an "N" in it.

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