Index
> Main > [suggestion] FASMINCLUDE environment variable |
| Author |
|
|
CandyMan 03 Apr 2018, 23:01
Maybe Tomasz add new internal directive that extend include paths. It can look this way:
Code: format ... ... IncludeAdd "..\SYSTEM;C:\DATA;" ; define paths include "file1.inc" ... When I am using windows's version fasm under hx dos extender it doesn't work for me INCLUDE environment variable. _________________ smaller is better |
|||
03 Apr 2018, 23:01 |
|
|
ProMiNick 03 Apr 2018, 23:07
use BAT script for compilation and force include from ini to replace global variable for script execution
Here only peace of script that peace extracts Include from INI & temporary replace global: for /f "delims= eol=" %%a in ('type "%~dp0FASMW.INI"') do ( for /f "delims==" %%b in ("%%a") do ( if %%b==Include set "%%a" )) ... "%fasm%" "%source%" "%output%" such way I create variable for fasmg includes so fasm & fasmg don`t conflict |
|||
|
03 Apr 2018, 23:07 |
|
|
revolution 03 Apr 2018, 23:45
This suggestion just keeps being suggested. The first reference I can find is more than 14 years ago. And there are many other threads that also discuss it. So far there has been no change in the naming.
|
|||
|
03 Apr 2018, 23:45 |
|
|
Jin X 04 Apr 2018, 09:12
So this problem is actual.
ProMiNick, now I use FASM.BAT that redefines INCLUDE for fasm (and other). But I create COMPILE.BAT for project compilation I need to run this .BAT via 'call' command. It's not good if I want to use it for project that other people can use 'cause thay couldn't have FASM.BAT for INCLUDE variable redefinition set... CandyMan, maybe but it's easy to add FASMINCLUDE or FASMINC (and also FASMGINC) variable than IncludeAdd (IncludePath, IncludePathAdd). |
|||
|
04 Apr 2018, 09:12 |
|
|
Tomasz Grysztar 04 Apr 2018, 10:34
Jin X wrote: ProMiNick, now I use FASM.BAT that redefines INCLUDE for fasm (and other). But I create COMPILE.BAT for project compilation I need to run this .BAT via 'call' command. It's not good if I want to use it for project that other people can use 'cause thay couldn't have FASM.BAT for INCLUDE variable redefinition set... Since you are already using batch files anyway, setting up a necessary environment for the tools before calling them is a natural thing to do in such frameworks. |
|||
|
04 Apr 2018, 10:34 |
|
|
CandyMan 04 Apr 2018, 19:59
maybe add the option -I in the command line?
|
|||
|
04 Apr 2018, 19:59 |
|
|
Tomasz Grysztar 04 Apr 2018, 20:39
-I is already taken by fasmg's command insertion option, it would have to be some other letter.
|
|||
|
04 Apr 2018, 20:39 |
|
|
Furs 05 Apr 2018, 12:17
To be honest, I agree with Tomasz (read a bit of his reasoning in the past) that command line options should not affect the assembly, especially "including crap from a central place" which is a pathetic idea to me.
To me it is particularly infuriating how (almost) every god damn open source project requires you to "install" packages for dependencies. For fuck's sake, I end up building in a VM or LXC (container) because I don't want to INSTALL ANYTHING just to compile an application (the VM/container will be in tmpfs, or a RAM disk for you Windows folks, so it doesn't trash my disk's filesystem etc). I am sick of this assumption. Why is it so hard to 1) bundle the headers with the project or 2) tell the user where to place them in a subdir of the project's directory. If such "copying" seems wasteful then simply symbolic link them. This solves literally all the build dependency hell or bullshit bugs with "pkg-config" or other pathetic crap that assume you "install" development packages (yuck). Environment variables like this are one of the culprits; people ask for them because they think "installing" headers in a "central place" is good practice (no, it's NOT!). ffs /rant off. 
(I can't just "let other users use it" or "nobody forces me to use it", that's in fact exactly the problem I have with "compiling other people's code", so yeah -- I'm sick of having to use a VM because they want you to clog up your system by installing garbage) |
|||
|
05 Apr 2018, 12:17 |
|
|
revolution 05 Apr 2018, 12:33
I like the idea of the source code explaining everything it needs*, rather than using the command line to piece things together**.
But the usage of the environment variable confuses things a little bit. It mostly requires that the user have a central place for common files, while at the same time allowing the central place to be moved or changed if required or desired. And then comes the problem of the actual common files and versioning. Code can break if a newer or older version of something common is used. We already see this with the "DLL hell" problem. And to "solve" this problem it can be tempting to make a copy of the common files and make them local to the project. But that means you have multiple copies of the same thing, and it becomes troublesome to have to find and update every copy to fix some bug, or add a new feature, or something. * with include, or library, etc. ** using switches and parameters and whatnot. |
|||
|
05 Apr 2018, 12:33 |
|
|
DimonSoft 05 Apr 2018, 14:25
revolution wrote: Code can break if a newer or older version of something common is used. We already see this with the "DLL hell" problem. And to "solve" this problem it can be tempting to make a copy of the common files and make them local to the project. But that means you have multiple copies of the same thing, and it becomes troublesome to have to find and update every copy to fix some bug, or add a new feature, or something. But since applying a fix or adding new feature are basically making a “new” version of the library we don’t want them for the projects where separate copy was being done to avoid possible problems with new versions  |
|||
|
05 Apr 2018, 14:25 |
|
|
DimonSoft 05 Apr 2018, 14:32
Furs wrote: To me it is particularly infuriating <…> because they think "installing" headers in a "central place" is good practice (no, it's NOT!). OMG, thanks for that! I’ll put my signature under every single word. It’s funny that having such “central place” is exactly in the opposite direction of high-quality code. revolution has just mentioned the versioning problem, and this is why. With “central place” one has to perform extensive testing for every project that relies on the “central place”. I really doubt everyone protecting such “central places” does that. And no, simply re-running automated tests is not enough unless we want to turn our customers into our testers. |
|||
|
05 Apr 2018, 14:32 |
|
|
revolution 05 Apr 2018, 14:33
DimonSoft wrote: But since applying a fix or adding new feature are basically making a “new” version of the library we don’t want them for the projects where separate copy was being done to avoid possible problems with new versions |
|||
|
05 Apr 2018, 14:33 |
|
|
revolution 05 Apr 2018, 14:35
DimonSoft wrote: And no, simply re-running automated tests is not enough unless we want to turn our customers into our testers. |
|||
|
05 Apr 2018, 14:35 |
|
|
DimonSoft 05 Apr 2018, 17:39
revolution wrote:
<OffTop> Raymond Chen once had a post in his blog where he stated that “official release version of Windows needs to be solid enough to survive a week without any help”. When the Internet was slow and not readily available it should have been solid enough to survive nearly forever. These days it seems you can’t even copy a file between two places on your hard drive without having a super-fast internet connection and a brand new Android 7.1 smartphone. </OffTop> |
|||
|
05 Apr 2018, 17:39 |
|
< Last Thread | Next Thread > |
Forum Rules:
|