Opened 4 years ago

Last modified 4 years ago

#3836 accepted enhancement

add WIN32 alternative to paths in .h.in files

Reported by: fdupont Owned by: fdupont
Priority: low Milestone: Windows
Component: Unclassified Version: git
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DHCP Feature Depending on Ticket:
Estimated Difficulty: 0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

In .h.in files there are auto tools macros and Unix style paths. The idea is to add the alternative for Windows taken from the win32 branch...

Subtickets

Change History (6)

comment:1 Changed 4 years ago by fdupont

  • Owner set to fdupont
  • Status changed from new to accepted

comment:2 Changed 4 years ago by fdupont

Note the alternative is to add Windows specific files but it is overkilling if #ifndef _WIN32 clauses are acceptable...

comment:3 Changed 4 years ago by fdupont

  • Summary changed from add WIN32 alternative to paths in ,h,in files to add WIN32 alternative to paths in .h.in files

comment:4 follow-up: Changed 4 years ago by stephen

When I was looking at the problem of moving BIND 10 to Windows a few years ago, the approach I was considering was to write a "sed"-like utility that performed the substitution as part of the Visual Studio build. (A possibility is to use GnuWin32 (http://gnuwin32.sourceforge.net) which contains a sed port.) I can't remember all the details, but I think I created multiple projects in the workspace. The main build project was dependent on a project that performed the substitutions.

I would prefer something like this to including #ifndef _WIN32 to the code. We could put the additional Windows files (including workspace and project files) in a separate git repository: Windows is not a target operating system, so this approach avoids the confusion that would ensue if people saw Windows-specific macros/branches in the code.

comment:5 in reply to: ↑ 4 Changed 4 years ago by fdupont

Replying to stephen:

When I was looking at the problem of moving BIND 10 to Windows a few years ago, the approach I was considering was to write a "sed"-like utility that performed the substitution as part of the Visual Studio build. (A possibility is to use GnuWin32 (http://gnuwin32.sourceforge.net) which contains a sed port.) I can't remember all the details, but I think I created multiple projects in the workspace. The main build project was dependent on a project that performed the substitutions.

=> I already have a nice perl script named Configure which does some substitutions... I know GnuWin32 but it is copylefted so IMHO should stay at most an option.

I would prefer something like this to including #ifndef _WIN32 to the code.

=> there are already some and a WIN32 (i.e., without the leading underscore, surely a typo :-) too. The problem is for code in .cc files I simply used a copy (and in a few cases something very different) in the win32 subdirectory where are already the project files. It is a bit harder for includes because the paths are already in the including .cc files. An alternative (used once for data_def_unittests_config.h is to copy the windows version of the include in the pre-build...

We could put the additional Windows files (including workspace and project files) in a separate git repository:

=> they are in the win32 branch. I can't see the need for a separate git repository...

Windows is not a target operating system, so this approach avoids the confusion that would ensue if people saw Windows-specific macros/branches in the code.

=> I can't parse the branches here (code branch, git branch, etc?)

comment:6 Changed 4 years ago by hschempf

  • Milestone changed from Kea-proposed to Windows
Note: See TracTickets for help on using tickets.