Are #ifdefs and similar define-dependent code intentionally stripped for dumped modules? I just recompiled a fresh 7.5 and noticed that I could not use -DHTTP_QUERY_DEBUG until I removed all .o files. :-7
There is no way to have defines in .o-files, they are already compiled.
/ Per Hedbor ()
Previous text:
2003-10-22 14:02: Subject: Defines and dumped modules
Are #ifdefs and similar define-dependent code intentionally stripped for dumped modules? I just recompiled a fresh 7.5 and noticed that I could not use -DHTTP_QUERY_DEBUG until I removed all .o files. :-7
/ Johan Sundström, Lysator
Ah, naturally. Dumping some dependency info too and disregarding the dumped version when run under different conditions would be nice.
/ Johan Sundström, Lysator
Previous text:
2003-10-22 14:03: Subject: Defines and dumped modules
There is no way to have defines in .o-files, they are already compiled.
/ Per Hedbor ()
This has been dicussed earlier but apparently it hasn't been implemented by anyone. For plain #ifdefs and #if constant()s, all that's needed is the ability to get a list from the preprocessor which defines/constants it has tested on, and the dumper can encode this list (together with the current defined/undefined status for each) and it can be tested when loading the dumped file if any of them have changed their status. For more complex #if expressions, it might become a bit more hair, but I think a conservative approach would be to use the dumped file iff all macros that are expanded in the source code still has the exact same value, and all the constants that are tested still have the same constant/non-constant status.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-10-22 14:08: Subject: Defines and dumped modules
Ah, naturally. Dumping some dependency info too and disregarding the dumped version when run under different conditions would be nice.
/ Johan Sundström, Lysator
When is it a problem?
A binary install package of Pike would compile the .o files on the target machine anyway, right?
/ Mirar
Previous text:
2003-10-22 14:02: Subject: Defines and dumped modules
Are #ifdefs and similar define-dependent code intentionally stripped for dumped modules? I just recompiled a fresh 7.5 and noticed that I could not use -DHTTP_QUERY_DEBUG until I removed all .o files. :-7
/ Johan Sundström, Lysator
The problem arises when you want to alter some define that affects how the core (dumped) modules behave; be it a constant, a debug flag or otherwise. HTTP_QUERY_DEBUG was very useful in tracking down why I got borked data from a web server today as soon as I did an HTTP POST. (It turned out Pike did not skip 100 Continue responses as it should.)
/ Johan Sundström, Lysator
Previous text:
2003-10-22 19:10: Subject: Defines and dumped modules
When is it a problem?
A binary install package of Pike would compile the .o files on the target machine anyway, right?
/ Mirar
Backport?
/ Martin Nilsson (saturator)
Previous text:
2003-10-22 22:46: Subject: Defines and dumped modules
The problem arises when you want to alter some define that affects how the core (dumped) modules behave; be it a constant, a debug flag or otherwise. HTTP_QUERY_DEBUG was very useful in tracking down why I got borked data from a web server today as soon as I did an HTTP POST. (It turned out Pike did not skip 100 Continue responses as it should.)
/ Johan Sundström, Lysator
Not much to backport to though since the problem I encountered was in Protocols.HTTP.Session, which only exists in 7.5 so far. :-) OTOH, it might be good to expose the static method in Query which is needed to implement the same recovery I did.
/ Johan Sundström, Lysator
Previous text:
2003-10-22 22:53: Subject: Defines and dumped modules
Will do, but not tonight.
/ Johan Sundström, Lysator
That's true. I remember deleting Query.o at occassion...
/ Mirar
Previous text:
2003-10-22 22:46: Subject: Defines and dumped modules
The problem arises when you want to alter some define that affects how the core (dumped) modules behave; be it a constant, a debug flag or otherwise. HTTP_QUERY_DEBUG was very useful in tracking down why I got borked data from a web server today as soon as I did an HTTP POST. (It turned out Pike did not skip 100 Continue responses as it should.)
/ Johan Sundström, Lysator
pike-devel@lists.lysator.liu.se
-
Johan Sundstr�m, Lysator ＠ Pike developers forum -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Nilsson (saturator) ＠ Pike (-) developers forum
-
Mirar ＠ Pike developers forum
-
Per Hedbor () ＠ Pike (-) developers forum