Include default FPC.CFG file
Original Reporter info from Mantis: L505
-
Reporter name: Lars(L505)
Original Reporter info from Mantis: L505
- Reporter name: Lars(L505)
Description:
I think FPC compiler should an option to include the default config file.. something like:
#INCLUDE DEFAULT_FPC_CFG
We currently have to bloat up the fpc.cfg file with this sort of noise:
#IFDEF NETBSD
#DEFINE UNIX
#ENDIF
#IFDEF LINUX
#DEFINE UNIX
#ENDIF
#IFDEF OPENBSD
#DEFINE UNIX
#ENDIF
#IFDEF FREEBSD
#DEFINE UNIX
#ENDIF
#IFDEF UNIX
#INCLUDE /etc/fpc.cfg
#ENDIF
#IFDEF WIN32
#INCLUDE c:\could\be\anywhere\
#ENDIF
#IFDEF WIN64
#INCLUDE c:\could\be\anywhere\
#ENDIF
Mantis conversion info:
- Mantis ID: 9450
- Version: 2.0.4
- Fixed in version: 2.2.2
- Fixed in revision: 8582 (#01fd4f55)
Activity
assigned to @jmaebe
added CategoryCompiler SeverityFeature Version2.0.4 labels
changed milestone to %Version 2.2.2
Converted from Mantis. Note by Marco van de Voort @marcoonthegit
- Mantis submitter username: marco @marcoonthegit
- Mantis submitter real name: Marco van de Voort
All those platforms already define "UNIX" since 1.0.6 or so. The location of that fpc.cfg is also default and auto searched. These are already built in
-
Apart from what Marco said, you also do not need to modify the default fpc.cfg to have some kind of default behaviour. You can create a .fpc.cfg in your home directory (on *nix) which contains #include /etc/fpc.cfg (or wherever the default fpc.cfg is located on your system), followed by your custom settings.
Please read the documentation for more information.
-
Converted from Mantis. Note by Lars(L505)
- Mantis submitter username: L505
- Mantis submitter real name: Lars(L505)
regardless of whether unix is defined or not, each person has a different fpc.cfg file location on Windows. Some unix systems might not store it in /etc/fpc.cfg but I'm not sure. For example, someone said to me his config file on BSD is in here
/usr/local/etc/fpc.cfgWhich means that once again, we have to pollute the fpc.cfg file up with noise to take into account all these paths, whether or not UNIX is defined. Actually at this point, the pollution is not the problem.. the problem then is that if we try and guess the correct path, someone's system may not use /etc/fpc.cfg, rather they will use /usr/local/etc/ and the compilation will be broken if the shipped fpc.cfg file doesn't contain that exact path.
I suppose I could just stop shipping fpc.cfg files altogether with demos.. and tell people to set up their own FPC.cfg files and search paths. But I like giving people a fpc.cfg file so it is extremely easy for them to compile demos without them having to do all the work. It's really an ease of use benefit. Kind of like the convenience of people being able to just type MAKE.
-
Converted from Mantis. Note by Lars(L505)
- Mantis submitter username: L505
- Mantis submitter real name: Lars(L505)
There is the global environment variable such as PPC_CONFIG_PATH to consider, but this means every single FPC user must first manually set that path up (which means broken compilation and frustration for users unfamiliar with it). Could this PPC_CONFIG_PATH somehow be accessed in the #INCLUDE directive?
#IFDEF LINUX
#INCLUDE PPC_CONFIG_PATH/fpc.cfg
#ENDIF#IFDEF WIN32
#INCLUDE %PPC_CONFIG_PATH%/fpc.cfg
#ENDIF???
The reason I like using local fpc.cfg files is because global fpc.cfg files are dangerous when versioning comes into play. If I add a bunch of -Fu paths to a global fpc config file in /home/user/ directory, this means big problems when I need to compile a program with unitxxx version 1.5 and the global config path has unitxxx version 1.6 path in it. That's why I never go into my /home/user/ directory and just modify it.. because that is globally dangerous for my development needs (I manage multiple copies of PSP/Powtils on the same hard drive and need to compile 1.5, 1.6, devel, etc.)
I always ship fpc config files that contain -Fu paths in them.. One of the reasons I'm reporting this bug is because whenever I ship fpc.cfg files with Powtils/PSP there is always, and I mean always serious problems with people compiling the programs (system.pp not found, etc). This is a serious 'ease of use' issue for FPC cross platform development I have found. I'd be happy to help work with you guys on a patch if you can confirm this feature would be accepted. Or if you have any other thoughts or ideas?
-
Converted from Mantis. Note by Lars(L505)
- Mantis submitter username: L505
- Mantis submitter real name: Lars(L505)
On my computer, this does not work:
#IFDEF UNIX
#INCLUDE /etc/fpc.cfg
#ENDIFThat's in a separate fpc.cfg file in my local directory of the program.
This does work below:
#IFDEF LINUX
#INCLUDE /etc/fpc.cfg
#ENDIFI realize in Pascal programs you can do this:
{
IFDEF UNIX}<br/> {ENDIF}But in a local config file in a program directory, as I can tell, I have to do this:
#IFDEF LINUX
#IFDEF FREEBSD
#IFDEF NETBSD
#IFDEF OPENBSD
#IFDEF WIN32
#IFDEF MACOS??
etc. etc.Rather than abstract ones:
#IFDEF UNIX
#IFDEF WINDOWS
etc.I'm using 2.0.4 and 2.1.x
Note: I'm not so sure if my syntax is correct for BSD and MAC, haven't had time to test. Just guessing there. But on my linux machine, UNIX doesn't seem to have effect in an empty config file in local program directory.
-
Converted from Mantis. Note by Marco van de Voort @marcoonthegit
- Mantis submitter username: marco @marcoonthegit
- Mantis submitter real name: Marco van de Voort
Hmm. There is indeed an oddity there. Auto (built in) platform initiation only seems to do "extradefines" later. While an explicit -T&LtPos;x> will.
E.g.
fpc -Tfreebsd blaat
will have "unix" defined in fpc.cfg and without -Tfreebsd not. (a -Tx at the top of the fpc.cfg will serve the same)
-
Converted from Mantis. Note by Lars(L505)
- Mantis submitter username: L505
- Mantis submitter real name: Lars(L505)
For the common path issue..
One idea I had was just to force people to make a PPC_CONFIG_PATH macro and then go something like so:
#IFDEF UNIX
#INCLUDE $PPC_CONFIG_PATH/fpc.cfg
#ENDIF#IFDEF WINDOWS
#INCLUDE %PPC_CONFIG_PATH%/fpc.cfg
#ENDIFShould that macro above work assuming the shell in windows/unix has the environment variable setup? I could ship some sort of installer that makes sure this shell variable is setup beforehand.
How come the freepascal installer doesn't set up PPC_CONFIG_PATH?
Well I'm trying to figure out how I determine the fpc.cfg path safely when shipping fpc.cfg files with demos.. I may just give up and have people create their own fpc.cfg files since I'm causing confusion/broken compilation when I ship them.
Another issue is MSEIDE users (and maybe lazarus) since MSEIDE dialog window doesn't know anything about fpc.cfg files but the compiler does, which causes more confusion since the fpc.cfg file is being used behind the end user's back. (this issue is not FPC team's problem or fault, it is just a point I wanted to make to myself to encourage myself to stop shipping fpc.cfg files with demos because they just cause problems for the end user who uses a good IDE, I think maybe I'll still ship the fpc.cfg file but rename it to fpc.cfg.sample and people can just see the sample file without it interfering if they don't want it interfering.)
Also should we open a separate feature/bug report for that EXTRA DEFINES target issue? It would be nice to have #IFDEF UNIX and #IFDEF WINDOWS capabilities without specifying -T
-
I don't think the fpc.cfg file was ever meant to be used in the way you are trying to use it. For such situations, fpcmake and its successor fpmake, IDE project files, or even plain shell scripts/batch files are more suited.
MSEIDE (and anyone else) can pass -n to the compiler, which makes it not read any configuration file.
Setting PPC_CONFIG_PATH in the installer would open a whole new can of worms on *nix with shell detection and modifying the appropriate rc/profile/login files. I don't know whether the Windows installer could do it easier by modifying the registry somehow.
I don't know about the -T thing.
-
Another thing: you can use the parameter "@someconfigfile" to pass a bunch of parameters to the compiler in addition to what it finds in the configuration files at the default search locations. This file can also contain #ifdef statements and all other things you can use in a regular configuration file.
This will still require your users to manually add @someconfigfile when compiling, but other than that everything is handled by the compiler as it is otherwise.