View Issue Details

IDProjectCategoryView StatusLast Update
0001973Slicer4Core: Building (CMake, Superbuild)public2012-05-11 06:05
Reporterpieper Assigned Tojcfr  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Product VersionSlicer 4.1.0 
Target VersionSlicer 4.1.1Fixed in VersionSlicer 4.2.0 
Summary0001973: SlicerFunctionToday does NOt handle foreign operating system / UTF-8 character
Description

Steve - 6/8/2011:

Hi Jc -

In CMake/SlicerFunctionToday.cmake there is a call to the windows
'date' command which results in non-english characters when running on
windows with a non-english language pack installed (we found this out
with Luping's build). This creates a problem in
vtkSlicerVersionConfigure.h and the build fails.

Does CMake offer an internationalized method to get the system date?

TagsNo tags attached.

Relationships

related to 0001974 closedjcfr Package name / Slicer_BUILDDATE should be associated with last commit date instead of the current date of the day. 

Activities

jcfr

jcfr

2012-05-03 08:07

administrator   ~0004148

Jc - 6/8/2011:

Internally, CMake relies on KWSys which handle dates (see here line 705). But the date/time methods are not exposed at the scripting level.

Not sure to understand the problem you described. The date is supposed to be numerical. Isn't it ? Is there special character displayed?

If you issue the command "cmd /c "date /T" in a windows terminal, could you send a screenshot of the result ?

If we don't find a obvious way to resolve that issue, I see the following option:
1) Relying on python to obtain the date [Don't like that since python is a build option]

2) "Try_compile" a small executable allowing to obtain the date

Thanks
Jc

jcfr

jcfr

2012-05-03 08:08

administrator   ~0004149

Steve - 6/8/2011:

Hi Jc -

We couldn't find a print-screen key on the laptop so I took a phone
photo and sent it to you.

The output comes up with the Chinese characters for "Thursday" after
the numeric date (the machine is set to Chinese time, so it's Thursday
already ;) In the English version the string is "Wed 2011-06-08".

I agree on the two options you mentioned. I don't see any easier
workaround that will be robust. For slicer purposes at this point I
think python could be considered a requirement, at least for the
purposes of making dated packages, so that is probably the easier
solution. Longer term I would suggest exposing the KWSys calls in
cmake as the more useful solution.

For now though we hacked around this issue on Luping's machine so it's
not a high priority fix. We'll see what other issues occur, but so
far Luping's build has been going for several hours so this may be the
only issue we see.

jcfr

jcfr

2012-05-04 14:01

administrator   ~0004170

Considering the function "SlicerFunctionToday" isn't used anymore. Will consider this issue is resolved.

See http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=20028

Issue History

Date Modified Username Field Change
2012-05-03 08:07 jcfr New Issue
2012-05-03 08:07 jcfr Status new => assigned
2012-05-03 08:07 jcfr Assigned To => jcfr
2012-05-03 08:07 jcfr Note Added: 0004148
2012-05-03 08:07 jcfr Reporter jcfr => pieper
2012-05-03 08:08 jcfr Note Added: 0004149
2012-05-03 08:12 jcfr Relationship added related to 0001974
2012-05-04 14:01 jcfr Note Added: 0004170
2012-05-04 14:01 jcfr Status assigned => resolved
2012-05-04 14:01 jcfr Fixed in Version => Slicer 4.x AHM Summer 2012
2012-05-04 14:01 jcfr Resolution open => no change required
2012-05-08 15:10 jcfr Target Version => Slicer 4.1.1
2012-05-08 16:52 pieper Status resolved => closed
2012-05-11 06:05 pieper Resolution no change required => fixed