2023-12-20 14:22 UTC-0500 Ron Pinkas <ronpinkas/AT/gmail/com>
* .gitignore
+ *.json
+ contrib/hbhpdf/tests/.gitignore
+ New for this dir
+ *.c
* bin/bld_vc.bat
+ Added detection of VS2022
+ Added assignment of respective __MSC__ version
* make_vc.bat
+ Added assignment of respective __MSC__ version
* bin/bld.bat
+ Added logic to default HB_INSTALL HB_BIN_INSTALL HB_LIB_INSTTALL and HB_INC_INSTALL
based on the directory from which bld.bat was loaded.
- Removed explicit HB_LIB_INSTALL for each library in MSVC section
+ Added /LIBPATH=%HB_LIB_INSTALL% to LDFLAGS in MSVC secttion
+ Added libharu.lib hbhpdf.lib and png.lib to default libraries (if exist) in MSVC section
+ Added enclosing "" around %HB_INC_INSTALL% in -I switch in MSVC section
* winmake/common.mak
+ Added hpdf_direct and hpdf_shading to LIBHARU_LIB_OBJS
* winmake/makefile.vc
+ Added CC_CMD_HARU
* winmake/compile.mak
+ Added hpdf_direct and hpdf_shading to HBHPDF.LIB dependencies
* Changed HBHPDF.LIB dependencies to use CC_CMD_HARU instead of CC_CMD
to use C compilattion instead of C++
* winmake/msvcerr.vc
+ Added messages for __MSC__ 16 and 17
Enrico,
I ended up "fixing" the MSVC build of libharu by simply forcing C mode instead of C++ compilation (no -TP switch).
[...]
There are still warnings for hbhpdf:
I ended up "fixing" the MSVC build of libharu by simply forcing C mode instead of C++ compilation (no -TP switch).
1. Some/Most BCC versions are not C99 compliant and thus produce error
on code like this:
for (HPDF_UINT32 i = 0; i < prec; i++) {
fpart_val = modff(fpart_val*10.0, &int_val);
*s++ = (char)(int_val + 0.5) + '0';
}
C Compiler need to support declaration of variable in the loop initialization.
C99 also added modff()
You told me that you use latest BCC and yet spoke about modff() missing
but this does not make sense since current standard math.h header must
have modff(). So we need to better review and understand BCC versions.
2. Errors on incompatible pointers. This happens due to C++ compilation
and you can fix it by ssimply switching to C compilattion.
Il 20/12/2023 21:06, Ron Pinkas ha scritto:
I ended up "fixing" the MSVC build of libharu by simply forcing C mode instead of C++ compilation (no -TP switch).
Great idea! I vaguely thought about that solution but I did not apply
it. Thank you!
Now an important (at least for me) question: we have to leave all the contribs alone or only hbhpdf? Can I continue to fix warnings in the
contrib directory or not? Please clarify.
There are still warnings for hbhpdf:
contrib\hbhpdf\hpdf_utils.c(223): warning C4244: 'function': conversion
from 'double' to 'float', possible loss of data contrib\hbhpdf\hpdf_utils.c(236): warning C4244: 'function': conversion
from 'double' to 'float', possible loss of data
contrib\hbhpdf\hpdf_encoder.c(2766): warning C4244: 'initializing': conversion from 'HPDF_UINT16' to 'HPDF_BYTE', possible loss of data
contrib\hbhpdf\hpdf_fontdef_tt.c(2070): warning C4389: '==':
signed/unsigned mismatch
contrib\hbhpdf\hpdf_fontdef_tt.c(2076): warning C4244: 'function':
conversion from 'HPDF_UINT32' to 'HPDF_UINT16', possible loss of data contrib\hbhpdf\hpdf_fontdef_tt.c(2077): warning C4244: 'function':
conversion from 'HPDF_UINT32' to 'HPDF_INT16', possible loss of data contrib\hbhpdf\hpdf_fontdef_tt.c(2087): warning C4244: 'function':
conversion from 'HPDF_UINT32' to 'HPDF_INT16', possible loss of data
contrib\hbhpdf\hpdf_font_cid.c(411): warning C4244: 'initializing': conversion from 'HPDF_UINT' to 'HPDF_UNICODE', possible loss of data
contrib\hbhpdf\hpdf_gstate.c(73): warning C4244: 'initializing':
conversion from 'float' to 'HPDF_UINT', possible loss of data
contrib\hbhpdf\hpdf_pages.c(1192): warning C4244: 'initializing':
conversion from 'float' to 'HPDF_UINT', possible loss of data
contrib\hbhpdf\hpdf_page_operator.c(24): warning C4244: 'initializing': conversion from 'float' to 'HPDF_UINT', possible loss of data contrib\hbhpdf\hpdf_page_operator.c(198): warning C4244: 'function': conversion from 'HPDF_REAL' to 'HPDF_STATUS', possible loss of data contrib\hbhpdf\hpdf_page_operator.c(202): warning C4244: 'function': conversion from 'HPDF_REAL' to 'HPDF_STATUS', possible loss of data contrib\hbhpdf\hpdf_page_operator.c(1189): warning C4244: 'function': conversion from 'HPDF_REAL' to 'HPDF_STATUS', possible loss of data
contrib\hbhpdf\hpdf_image.c(202): warning C4456: declaration of 'ret'
hides previous local declaration
contrib\hbhpdf\hpdf_image.c(176): note: see declaration of 'ret'
contrib\hbhpdf\hpdf_image_png.c(351): warning C4018: '<':
signed/unsigned mismatch
contrib\hbhpdf\hpdf_pdfa.c(154): warning C4189: 'info': local variable
is initialized but not referenced
contrib\hbhpdf\hpdf_encoder_utf.c(172): warning C4244: 'return':
conversion from 'unsigned int' to 'HPDF_UNICODE', possible loss of data contrib\hbhpdf\hpdf_encoder_utf.c(133): warning C4100: 'code':
unreferenced formal parameter
contrib\hbhpdf\hpdf_image_ccitt.c(410) : warning C4706: assignment
within conditional expression
contrib\hbhpdf\hpdf_image_ccitt.c(469) : warning C4706: assignment
within conditional expression
There are still warnings for hbhpdf:
Do I have suppress them using compiler switches like -wdxxx in my build
batch? Let me know.
I would not supress so we don't hide things we do need to fix. I think
we should report it, and possibly suggest a pull request with proposed
fixes.
My answer is a mix bag :)
1. Code in contrib that is part of xHarbour (like wrappers), in separate sources, should always be fixed.
2. Original 3rd party sources of live projects should not be modified, instead it shoulld be reported to respective maintainers (like GitHub
issue). Or, creative fixes that do not modify ooriginal sources.
3. Code borrowed from dead, unmaintained projects should be fixed.
This is just my idea, I hope it makes sennse.
Il 21/12/2023 11:28, Enrico Maria Giordano ha scritto:
There are still warnings for hbhpdf:
Do I have suppress them using compiler switches like -wdxxx in my build batch? Let me know.
Il 20/12/2023 21:06, Ron Pinkas ha scritto:
1. Some/Most BCC versions are not C99 compliant and thus produce error
on code like this:
for (HPDF_UINT32 i = 0; i < prec; i++) {
fpart_val = modff(fpart_val*10.0, &int_val);
*s++ = (char)(int_val + 0.5) + '0';
}
C Compiler need to support declaration of variable in the loop initialization.
C99 also added modff()
You told me that you use latest BCC and yet spoke about modff() missing
but this does not make sense since current standard math.h header must
have modff(). So we need to better review and understand BCC versions.
If those are the requirements then we have no other choices than
dropping support for bcc32.exe and forcing use of bcc32c.exe.
But I
don't think we have to do that. I just built xHarbour for BCC32 using bcc32.exe and found no errors and no warnings (using only -w-prc
-w-use). So what's the problem?
2. Errors on incompatible pointers. This happens due to C++ compilation
and you can fix it by ssimply switching to C compilattion.
Ok, I will keep it in mind for the future.
Il 21/12/2023 17:01, Ron Pinkas ha scritto:
There are still warnings for hbhpdf:
Do I have suppress them using compiler switches like -wdxxx in my build batch? Let me know.
I would not supress so we don't hide things we do need to fix. I think
we should report it, and possibly suggest a pull request with proposed fixes.
Don't look at me. :-)
Il 21/12/2023 16:58, Ron Pinkas ha scritto:
My answer is a mix bag :)
1. Code in contrib that is part of xHarbour (like wrappers), in separate sources, should always be fixed.
2. Original 3rd party sources of live projects should not be modified, instead it shoulld be reported to respective maintainers (like GitHub issue). Or, creative fixes that do not modify ooriginal sources.
3. Code borrowed from dead, unmaintained projects should be fixed.
This is just my idea, I hope it makes sennse.
Yes, it makes perfect sense. Only one more question: how to recognize a xHarbour contrib code? Is the presence of #include "hbapi.h" enough?
Please confirm.
Don't look at me. :-)
This is all volunteer work, so no :), but since you already made the
fixes, I think you sure can make the contribution available as a pull
request proposal. You do deserve the credit.
Yes, it makes perfect sense. Only one more question: how to recognize a
xHarbour contrib code? Is the presence of #include "hbapi.h" enough?
Please confirm.
Yes in general this should be true. Sadly contribs have been maintained
in a loose manner and I suspect there are some "mix" sources. So I think
if someone care enough then reading the copyright and general review of
the code should make it clear. I would try to at least not ADD such mix
code. The best choice is to keep 3rd party sources separate and
unmodified.
I just built xHarbour for BCC32 using
bcc32.exe and found no errors and no warnings (using only -w-prc
-w-use). So what's the problem?
Sure. We are not going to force anything, we can keep xHarbour code
compliant with even older compilers. It's only 3rd party code (in
conribs) that might not compile by all compilers. If we prefer to keep
using latest versions of 3rd party in contribs then we have to
understand that such code migh not support old compilers.
Il 21/12/2023 17:17, Ron Pinkas ha scritto:
I just built xHarbour for BCC32 using
bcc32.exe and found no errors and no warnings (using only -w-prc
-w-use). So what's the problem?
Sure. We are not going to force anything, we can keep xHarbour code compliant with even older compilers. It's only 3rd party code (in
conribs) that might not compile by all compilers. If we prefer to keep using latest versions of 3rd party in contribs then we have to
understand that such code migh not support old compilers.
I do not understand. Why I'm not getting any errors building current repository with BCC32? What am I missing? Is the modff() problem
vanished into thin air?
I do not understand. Why I'm not getting any errors building current
repository with BCC32? What am I missing? Is the modff() problem
vanished into thin air?
I beleieve its because I made change to common.mak using a compile
command CC_CMD_HARU that was not yet implemented in makefile.bc so
it may have not compiled it at all. I just fixed to use CCC_CMD which
is defined in all compilers make files, and I am now testting.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 714 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 140:28:54 |
| Calls: | 12,087 |
| Files: | 14,998 |
| Messages: | 6,517,424 |