revolution
I didn't say, one should use full paths, but your suggestion is to introduce many more limitations. Say there's a library that includes its files using relative paths (similar to win32a.inc). Some files can be included as a part of the library or individually. The relative paths would be different. How restrictive should be your rules to avoid this?

That's not mentioning that soft and hard links are possible in both Windows and Linux. Taking that into account shows that C-style inclusion duplication prevention is the only correct way. Just consider what you'd do to compile a project making use of soft links on a system that has no support for them.

That's not mentioning that soft and hard links are possible in both Windows and Linux. Taking that into account shows that C-style inclusion duplication prevention is the only correct way. Just consider what you'd do to compile a project making use of soft links on a system that has no support for them.

I agree. I never said this was a proper or complete solution. It is not. But if one wants to make to most of it then such self restrictions can help to make it less error prone to use.

revolution
I have nothing against some rules of project organization. I'm just saying that the only reason to implement "include once" natively is the ability to unambiguously identify files, and if even this advantage is ignored, then it's just useless.

Again, once is a user-typed hint to overcome standard behaviour of fasm.
It does nothing to fasm structures, keeping inclusion order as described in official manual.
What it really does: when fasm is just about including a file, once checks for its presence and does its job.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum