-
Notifications
You must be signed in to change notification settings - Fork 2
/
Diary.txt
executable file
·1610 lines (1202 loc) · 100 KB
/
Diary.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
/*********************************************************\
* General diary for anything non directly per project related
\*********************************************************/
>> 30.12.2012
[CO]
- License change from "LGPL 3 License" to "MIT License" which is also known as "X11 License" or "MIT X License" (mit-license.org)
>> 21.08.2012
[CO]
- Since Git commit
"
Revision: fbcb91d7c4eac6f3882a8ee8e1ca7f49f98ba188
Author: Stephan Wezel
Date: 19.08.2012 13:47:59
Message:
Reviewed Commit 7228460cdd92877c1cf665ab1f8f589155797649: Disable windows only projects under non windows build target when CMAKETOOLS_SDK is set
Added a warning when PL_PLUGIN_ENGINE_POSTPROCESS is set but not PL_PLUGIN_RENDERER_OPENGLCG
(-> Some postprocess effect doesn't work without Cg support)
----
Modified: PixelLight/PixelLight.cmake
"
There's now always the red output warning
"
CMake Warning at PixelLight/PixelLight.cmake:562 (message):
PL_PLUGIN_ENGINE_POSTPROCESS needs PL_PLUGIN_RENDERER_OPENGLCG ->
Postprocess effects might not work
Call Stack (most recent call first):
CMakeLists.txt:40 (include)"
"
when cloning the Git repository and building PixelLight using CMake without additional configuration. I assume that this will lead to questions
like "Why do I always get a red warning?" In general, such validation checks are fine because they reduce ?!?! later on. Currently the Cg external
dependency is marked as "nonpublic". I read the Cg licensing terms again carefully and
"
2.1.1 Rights. Customer may use, reproduce, distribute, publicly display and publicly
perform the SOFTWARE.
"
sounds to me as if I it's allowed to distribute content of the Cg SDK. There's no paragraph about additional restrictions like within the DirectX SDK
which tells you that you are only allowed to redistribute the official redistributable files, which do not contain headers or libraries.
I looked around in the Internet to see whether or not I understood this correctly. The Ogre external packages at
http://ignum.dl.sourceforge.net/project/ogre/ogre-dependencies-vc%2B%2B/1.9/OgreDependencies_MSVC_20120819.zip
contains Cg SDK content as well as
http://trac.cafu.de/browser/cafu/tags/new-repository-init/ExtLibs/Cg?rev=526
http://code.google.com/p/shadertest/source/browse/trunk/Cg/include/Cg/cgGL_profiles.h?r=2
so it appears to be fine to redistribute those files.
-> Made the Cg external package "public" and enabled Cg support by default. This means that there's no longer a red warning when just using
default configurations.
>> 19.08.2012
[CO]
- "PixelLight.cmake": Added "CMAKETOOLS_SDK"-trigger which is similar to the "CMAKETOOLS_MINIMAL"-trigger. When "CMAKETOOLS_SDK"
is active when first configuring the CMake project, only the projects will be enabled which should be within the public
PixelLight SDK.
>> 18.08.2012
[CO]
- Saw the "PL_Volume isn't compileable with gcc 4.4.x -> deactivate it completely"-change
15.08.2012
"SHA-1: c4e7cae6b3e5a3e8249211f99f73ea8f661cb538"
* PL_Volume isn't compileable with gcc 4.4.x -> deactivate it completely
-> Added a TODO as well as an error message so that it can be seen that there's currently something not working
(otherwise one might wonder why the volume projects are not buildable, but only when using a particular GCC version :)
-> Interesting, the project is usual C++ code. As far as I remember I tested it with a GCC version (don't remember which)
and it compiled. Probably some usual C++ compiler difference and the code just needs a minor update. Would be nice
to know what's going on. :D
-> Removed the "CMakeList.txt" check to keep the change as local as possible without having the risk of forgetting to remove
this later on when the project is compiling, should still be deactivated for this GCC version
- The next planned release is PixelLight 1.0.0-R1 which will be released on August 19, 2012 if no problems occur. This time it's
not the 23'th and the last release is now older then two months. It's hard to keep a fixed release cycle within a spare-time
project when the "real"-life undergoes some heavy changes.
We started the development of PixelLight back on 16 September, 2002 and made the first public PixelLight 0.9.2-R1 release on
August 23, 2010. Two years below version number 1.0.0 has to be enough and over the past few months only a few major changes
were made, but a lot of bug fixes. It's also time for some more major changes in the PixelLight project which will e.g. break
interfaces. So, there are a lot of reasons for the 1.0.0 version cut and now starting the development of PixelLight 2.0.0 while
maintaining the current state as 1.x.x. It would be cool if we would find some additional maintainers for PixelLight 1.x.x.
It will probably take some time until PixelLight 2.0.0 will be as stable as PixelLight 1.0.0, but now we have the opportunity to
make some bigger changes:
- Since two and a half months I work on a new renderer system. The currently used PLRenderer project was started back in 2002
and was since then incrementally updated. Since then, the graphics APIs like OpenGL or DirectX have undergone dramatic changes
from fixed function to 100% shader based without fixed function support. APIs like DirectX are now heavily buffer oriented
and individually set render states are no longer appropriate - and OpenGL also changes into this direction. This just the
tip of the iceberg. Parallel with the renderer system, implementations for OpenGL (1.x-4.3), OpenGL ES 2 (probably soon also for 3)
and DirectX 9 & 10 & 11 as well as a lot of renderer examples from most primitive, showing several basic features up to fully lit
3-D models are written. That's why it takes so long. Replacing the current PLRenderer project with the new one will probably also
be a lot of work and I assume several legacy features will be dropped in this process.
- PixelLight was designed in a way where every module/plugin is a shared library. While this approach is still good, it does not
work well with some new platforms/systems introduced in the past few years. For instance NaCL requires that everything is statically
linked, and as far as I can see iOS has the same requirement. The Android port is currently using shared libraries. While this
works with some tricks, I assume for this port it would also be more efficient to use only statically linked libraries inside the shipped
APK file. Statically building and using PixelLight in this way is working in general, I already made experiments. But several RTTI
classes will be thrown away by the linker because for the linker it looks like those are unreferenced symbols. I already figured
out some hacks to some kind of solve this, but nothing I would dare to commit in the repository. So, there's probably a refactoring
required to be able to use PixelLight without any issues as shared library or static library.
- There's another RTTI related issue: The header size
Currently, all RTTI declarations are made inside headers. While the design is fantastic and it makes fun to use the system, the header
size and number of symbols defined inside headers quickly reach a point were the compile and link times are really getting painful. One and
a half year ago, when adding scripting support, I already had to use a light-hack inside the headers to only process RTTI method
declarations inside the project they are owned by. Back then I had to add a lot of RTTI methods and in the end the compile and link times
reached a level were it was no longer really possible to continue the development in a reasonable way. This means that there's need
for some refactoring by moving everything possible from the header into the source file of a RTTI class - without sacrificing fancy RTTI
features making PixelLight in my opinion unique in the open-source world.
... those are just a few reason for PixelLight 1.0.0 and PixelLight 2.0.0 ...
>> 16.08.2012
[SW]
- Under Linux changed the name of the binaries of the Samples and PLViewer/PLViewerQt to have the suffix "-bin".
Additional for these applications a shellscript is generated with the name without the suffix.
The shellscript is only installed via an make install, because the install prefix is used to setup the path to the runtime directory inside the script.
The shellscript setups the environment so that the Samples and the two Tools can run out of the box.
The downside of this change: the name of the configuration and logfiles changes for the sample apps and the two viewers.
The default name for the two files are generated by using the executable name.
>> 19.06.2012
[CO]
- When using Clang on Mac OS X, it appears that "-Wswitch-enum" is set by default resulting in a lot of warnings like
"warning: enumeration value ‘<x>’ not handled in switch"
I assume it's possible to just deactivate this warning, on the other hand, warnings are usually good in order to detect
real bugs. I already handled many of those warnings, but not all, yet (as mentioned, there are a lot of those warnings).
- Added the plugins PLLoaderDICOM_GDCM, PLLoaderPVM, PLVolume, PLVolumeRenderer and PLVolumeGui I wrote as part of my
master thesis "Scalable Realtime Volume Rendering". See the diary within the "Plugins/PLVolume"-directory for details.
>> 18.06.2012
[CO]
- PLInstall: When building the project with the Visual Studio project file, the Qt dlls are now copied into the runtime
directory. This way, it's possible to just build PLInstall and then being able to start the program at once.
>> 27.05.2012
[CO]
- Visual Studio project files: In debug build, changed "Basic Runtime Checks" to "Default" in order to enhance the performance
while debugging. Within the dungeon demo, I now have within my test 20 FPS instead of 10 FPS.
-> See http://randomascii.wordpress.com/2011/07/22/visual-c-debug-buildsfast-checks-cause-5x-slowdowns/ for details
>> 15.05.2012
[CO]
- Started playing around with Google Native Client (NaCL)
>> 30.12.2011
[CO]
- Visual Studio project files of Qt based projects: The generated ui files are now within "build\GeneratedQtFiles"
>> 29.12.2011
[CO]
- Visual Studio project files of Qt based projects: The generated moc and resource files are now within "build\GeneratedQtFiles"
>> 23.12.2011
[CO]
- Did the usual automatic checks
-> Source code spell check
-> Fixed issues found by "Cppcheck 1.52" (interesting: also "C-style pointer casting" was blamed)
-> Fixed issues found by the static code analysis of Microsoft Visual Studio 2010 Ultimate
>> 21.12.2011
[CO]
- Replaced "PLEngine::SNMLookController" with "PLEngine::SNMEgoLookController" and "PLEngine::SNMOrbitingController" with "PLEngine::SNMEgoOrbitingController"
to have no spinning effect which is confusing several persons :D
>> 22.12.2011
[SW]
- Linux: The XXX_RTTI_EXPORT "Hack" (the define was always set to 1) is now only used, when the visibility feature isn't used (either not activated or not supported).
Because now the compiler instanciate the templates for RTTI elements more then once in conjunction with the visibility feature, which the Hack was initially introduced to solve.
- Linux: The XXX_RTTI_EXPORT "Hack" must be also activated when the gcc 4.4.x is used (even with visibility feature active).
>> 15.12.2011
[CO]
- PLInstall: Under Windows, the executable has now an icon
- PLInstall: Qt wasn't showing me any icon in it's window, only the Windows default icon. When setting an Qt application icon by using
"QApplication::setWindowIcon()" it works, but only when not using a "ico"-file.
- Linux x64 - "PixelLight.cmake": Disabled projects were we don't have prebuild external packages, yet. The PixelLight default configuration
has to build out-of-the-box in order to avoid negative feedback like http://sourceforge.net/tracker/?func=detail&aid=3443335&group_id=507544&atid=2063684
-> Not tested due to lack of Linux x64, would be nice if someone can test this
-> The tracker post above mentions that PL_PLUGIN_FRONTEND_QT is not working under Linux x64, altought there's a prebuild package available and
Stephan Wezel is using it, hm
-> In CMake there's also the option to mark something as "advanced" so that it doesn't show up in the CMake GUI as long as no advanced stuff should be
shown. I'am not sure whether or not we should use this "advanced"-option to hide projects not working out-of-the-box... this may lead again to feedback
like "PixelLight is not compiling" even when just an optional plugin is not compiling... but someone new to PixelLight can't know that and may lose
interest in PixelLight at once when it's not even compiling...
>> 29.11.2011
[CO]
- CMake: As discussed in the research project meeting yesterday: Added a trigger to make it possible to disable the build of the samples
- PLInstall: Code style review
- PLInstall: Visual Studio project file: Disabled annoying "warning C4127: conditional expression is constant"-warning, it's within the Qt
headers were we can't change anything in there :/
- Some Visual Studio project files were not set to "Level4 (/W4)" warning level in debug mode (3ds Max exporter projects are intentionally set
to "Level3 (/W3)", warning level 4 makes no sense in there due to the mass of resulting warnings within the used external headers)
>> 24.11.2011
[CO]
- PLInstall: Updated "CMakeLists.txt" in order to make it work
- MS Windows 64 bit: It's now possible to build PixelLight also using CMake for this target (building an installable SDK is not tested, yet)
>> 22.11.2011
[CO]
- Visual Studio project settings: Fixed "warning MSB8012: TargetName does not match the Linker's OutputFile property value" by
removing the "OutputFile" setting, removed also the "ImportLibrary" setting (the default values are just fine)
>> 14.11.2011
[TM]
- PLInstall: Updated the installer. This includes an new Qt Gui and some changes in the PLCore runtime backend.
>> 01.11.2011
[CO]
- Fixed CMake warning "CPack.cmake has already been included!!" which came up in newer CMake versions by testing whether or not the variable
"CPack_CMake_INCLUDED" has already been defined (we include CPack in "Pack-Docs.cmake", "Pack-Runtime.cmake" and "Pack-SDK.cmake", do also see entry
28.07.2011 within this diary)
- CMake based build system: There were questions about the options "PL_NATIVE_PLPROJECT" and "PL_MOBILE" and I was just able to say "ignore those two
options". In order to avoid such questions in the future, those variables are no longer visible within the CMake-GUI. They are set by toolchains.
- CMake based build system: Removed the error prone "PL_TOOL_PLPROJECT"-option which was also visible in the CMake-GUI meaning a user was able to
disable it... which usually results in a lot of errors when building and/or using PixelLight...
- CMake based build system: When building the target "Pack-SDK" within the Visual Studio IDE, PLProject didn't work from time to time for a certain,
varying project. Visual Studio just hang for a few seconds and then aborted the post-build step with a lot of errors. I finally took the time to have
a look into this... I noticed that CMake had changed the absolute path to PLProject to a relative one.
For example "E:\PixelLight\pixellight_build\Bin-Windows\Runtime\x86\PLProject.exe" was automatically changed into "..\..\..\Bin-Windows\Tools\x86\PLProject.exe".
After changing it manually back to an absolute path, the error within Visual Studio was gone. To solve this issue, I set a working directory within the
"pl_plproject"-macro inside the "PixelLight.cmake"-file. It looks like that this PLProject/CMake/VisualStudio related error is now finally gone.
>> 27.10.2011
[CO]
- "profile" shell script: Added OS detection of Linux and Mac OS X
>> 14.10.2011
[CO]
- PixelLight can now be compiled for Mac OS X, next stop: Making the plugins ready
>> 12.10.2011
[CO]
- Another Apple day. Luckily there are build instructions available explaining how to compile GCC 4.6 on Mac OS X. Took ages to compile on the "Mac Mini".
Used the time to get more familiar with the Mac OS X system. Did some Xcode configuration so that it's usable, found a reasonable Git GUI client called
"GitX"... and started to no longer click on the not existing right mouse button. *g*
As mentioned, when using the terminal, one can reuse the Linux knowledge. Compiling libz and libpcre was therefore quite simple, "configure" & "make" and
it's done.
>> 10.10.2011
[CO]
- Started Mac OS X port... I'am sure the first Git commits from me will be full of errors, I don't have any previous experience with Apple hard- and software.
Installed Git and CMake and did a first test at once... and it really started compiling PixelLight. When using the terminal, Mac OS X is quite similar to
Linux. The build process by using CMake is also the same... use cmake-gui, click around, and then type "make". After the first few compiled files the expected
errors appeared. The usual minor POXIS header differences. Also, Mac OS X 10.6.8 I have available at my university only comes with GCC 4.2.1... I actually did
manage it to compile PLCore by removing some compiler switches. When it came to linking, there were the usual template instanciation issues known when using
out-of-date compilers. So, to continue, I have to get GCC 4.6 on this Mac OS X system...
>> 14.09.2011
[CO]
- Android port progress: Loading files (= assets) from apk is working as well as the sample "60Scene" (without shadow mapping, but with dynamic lighting)
- Android port related: Tested with "armeabi-v7a" (tested with "armeabi" before), works quite fine as well
- Android port related: "67Game2D" is running (but currently without input)
- Android port related: "70SPARK" is running (but currently without input)
>> 13.09.2011
[CO]
- Android port progress: "51RendererTexturing" & "54RendererRTT" (without MRT) are now running as well on my smartphone
>> 12.09.2011
[CO]
- WOW, PixelLight is running on my "LG P990 Optimus Speed"!
-> It looks like my roadmap from month ago is really working... the frontend refactoring was a step towards Android support (as well as webbrowsers :)...
my goal was that one can develop native applications as usual with e.g. Visual Studio for desktop PC, with comfortable graphical debugging etc... and then when an application should be "ported" to e.g. mobile
devices, it should only be required to recompile the native application into a shared library instead of an executable. That's all. On Android, even native applications have to go though Java, even when it's
an native activity. So, the native application must be a shared library. That's also the reason why it was important to me to be able to use OpenGL ES 2.0 nativly on my desktop PC - so that I'am able to develop
on and for an desktop PC... it's really no fun to debug with command line or by just using log outputs.
-> It looks like that this approach works really good... just compiled "50RendererTriangle" & "52RendererMesh" as "so", and my experimental Android frontend (not yet within PLFrontendOS) can load in and use the given
RTTI application class at once. This CMake frontend project also creates automatically a mini Java file which is responsible to load in the shared libaries (this doesn't happen automatically in Android!). Everything
an apk requires is configurated automatically by this CMake script, the apk is packed and optionally signed for release, it's also automatically directly moved to the device - meaning I just have to say "do it" and
after 5-10 seconds I see my application on my LG P990. :D
-> When using e.g. Lua scripts, it's not even required to recompile an application, that's why adding script support month ago was so important to me. I'am sure that this will be the preferred way to go... just writing
applications using scripts, and then "publishing" it by using a default precompiled PixelLight runtime apk.
-> I was afraid that PixelLight would consume to much memory by default, would be to slow and so on - but it's the opposite, my PixelLight app starts faster then on MS Windows! (including the setup of a huge
number of RTTI classes) Right now, I can't see memory or performance issues - I hope that more complex applications are also possible... meaning to just recompile existing projects into an "so"-file
and then directly running them on the mobile device. I'am sure that fine tuning is a little bit more work - the mobile devices usually have other texture compression formats. There's no mouse, only touchscreen
by default etc. - but just details. *g*
-> Enough for today, right now I'am somewhat too exited that it's finally working as planned, without real problems. PixelLight on a smartphone, wow. The next steps should be more fun then the last past two weeks...
it was often frustrating to get into native Android development, to understand all the tools, getting more into development under Linux, getting more into CMake, working out the workflow, how an apk is generated
and then trying to make this to an automatic CMake process, porting PixelLight using the Android NDK, solving some minor issues, some hours with several crashes (other behaviour of POSIX functions!!) on Android
until I saw something, or not... and in the end I noticed that the Android Emulator doesn't support OpenGL ES 2.0... and my "LG P990 Optimus Speed" no Android 2.3 because LG *still* has no official updated published...
so, I was at a dead end with the Android Emulator and had no other choice as to root my mobile device the first time in order to install a custom Android 2.3 rom. Lucky me that there's "CyanogenMod"
(http://www.cyanogenmod.com/). I was really impressed how easy it is to get this on an Android device, just root with a nice one-click-tool (I love such tools *g*), install "Clockwork Recovery" on the device, download
CyanogenMod, put CyanogenMod on the device, boot the device and get into the boot manager and a few seconds later the new custom rom is installing... and a few minutes later, tata, Android 2.3! Now I'am really happy
that I just did it instead of waiting for LG even longer for an official update... and shortly after Android 2.3 was running, PixelLight was running on Android. :D
(ok, I assume that the last steps were only so easy because I worked relativly slowly in the last past weeks so that I was able to see potential issues and resolving them before they cause an problem on
the device :)
>> 06.09.2011
[CO]
- Finally! Took me quite some time to figure out the "crtbegin_so.o: No such file: No such file or director" linker issue when compiling for Android. For this, I stopped for two days to get to the very
basics... building with Unix makefiles, building with Android NDK makefiles, building with CMake... and writing everything step by step down... including how to install and configurate everything as well
as some Linux console basics for MS Windows folks like me (imagine someone has no real Linux experience and wants to compile for native Android by using Linux). Maybe I publish the stuff later as tutorials
how one can build native applications for Android by using Linux... sadly, most information one can find in the Internet and even on Google's own documents is out-of-date.
-> Our CMake macro "define_project" justs resets *all* compiler and linker settings carefully set by the Android toolchain helper script. Tried a few minutes to fix it - but to be honnest, after this long
search I currently don't spend more hours with the CMake build system and therefore, I just added a "CMAKETOOLS_CONFIG_NO_FULL_CONTROL" variable disabling the compiler and linker setting reset.
"Toolchain-ndk.cmake" defines "CMAKETOOLS_CONFIG_NO_FULL_CONTROL" and so, the linker error is finally gone. Maybe I find a better solution later... later, not now... :D
-> By the way, it looks like the not so funny (in fact, absolutly annoying!) character eating bug described on "31.08.2011" doesn't happen when using Linux - maybe the Android NDK standalone toolchain for
MS Windows is broken? Also, compiling is muuuuuch faster when using Linux - and the "-j" make option also works, meaning it's possible to use all available CPU cores for compiling. When I sum up
everything I learned in the past few days... using MS Windows to compile native Android applications is a no-go, far too complicated, to slow, to buggy - just unusable and a waste of time. :/
-> Stephan Wezel rewrote "PLCore::SemaphoreLinux", it's now using POSIX semaphores, ok, this port point is also done
-> For a minimal build, PixelLight now only depends on PCRE as external third party library. I had a look into POSIX regex, Android 2.3 supports it correctly (tested it) - but the regular expression syntax
is another one used by PCRE, so, we can't really use POSIX regex.
-> I also noticed that "armeabi v7a" is not working within the Android Emulator, it just crashs. There's no "armeabi v7a"-target available. For the Android emulator, "armeabi" must be used. This means that I
have to provide two kinds of external dependencies packages, one for "armeabi v7a" and one for "armeabi" because I also want to support the Android Emulator (right now the official Android 2.3 for LG P990
Optimus Speed is still not available, but should be in a few days... eventually... if it's not, I have to use e.g. Cyanogenmod, but something "official" would be better for testing *g*).
- Cool, I just compiled PixelLight (minimal build: all 12 base projects, PLRendererOpenGLES2, PLViewer and the samples) for Android without any errors... I think I'am able to test it tomorrow when the rest like
Android frontend and apk creation is implemented. When everything is working, CMake is REALLY cool... the build process of PixelLight for MS Windows, Linux and Android is identical and the few settings
can be done within the CMake GUI. :D
>> 04.09.2011
[CO]
- Added triggers within "PixelLight.cmake" so one can exclude the external dependencies "libpng" and "libjpg", within the minimal-build they are excluded by default
>> 31.08.2011
[CO]
- Ok, the Android port is starting to come to life... but there are still some not so funny issues (don't now what's MS Windows related I'am currently using):
- There must be a memory leak or so within "arm-linux-androideabi-g++.exe" due to an issue I just can't pinpoint because it's frequently "jumping".
When linking, I receive a single error like "... arm-linux-androideabi-g++.exe: CMakeFies/PLCore.dir/src/File/FileSearchLinux.cpp". Note the
"CMakeFies" which should be in fact "CMakeFiles" and when checking all makes files and everything else, it's "CMakeFiles" and not "CMakeFies". But
it's not limited to this character, sometimes it's "CMakeFiles/PLCore.dr/src/File/FileSearchLinux.cpp" and so on - it's not even limited to this one
file, sometimes it's that file, then another one. But only one file at a time within PLCore.
When linking PLRenderer it's the same with "arm-linux-androideabi-g++.exe: ../PLRendeer/libPLRenderer.so.0.9.9: No such file or directory". Should be and is
"../PLRenderer/libPLRenderer.so.0.9.9". I already used other "make" versions and so on, nothing solves this issue. It will be interesting to see whether it's
the same when using Linux.
- Another issue: When using "Android NDK r6" and "API level 8" all is fine, when using "Android NDK r6" and "API level 9" I receive
"... arm-linux-androideabi/bin/ld.exe: warning: type and size of dynamic symbol `__dso_handle' are not defined" linker warnings. It's in fact a bug within
"Android NDK r6" and solved within "Android NDK r6b" (see http://code.google.com/p/android/issues/detail?id=19597).
When using "Android NDK r6b", the warning is in fact gone - but has been replaced by the following error "crtbegin_so.o: No such file: No such file or directory"
... another issue I tried to resolve for at least one hour without any solution. Another Android NDK bug? Did I messed up something somewhere? So, I have to stick
with "Android NDK r6" for now to get some general real progress with the Android port without loosing myself into this issue.
- Compiling is really slow, it takes ages :/
-> Beside those still remaining issues, and a required rewrite of "PLCore::SemaphoreLinux" because the Android NDK doesn't support the features used by the current
implementation, I'am now able to compile all 12 base projects for Android. Of course this doesn't mean that the port is finished or near to finished. :/
-> In general, I decided to use Android 2.3 (Gingerbread, "android-9" NDK API level) for PixelLight even if I started the port by using API level 8 because my smartphone
(LG P990 Optimus Speed) was shipped with Android 2.2.2 and there's still no official Android 2.3 update. I try to avoid to hack around on the device (at least for now).
But Android 2.3 introduced several really decent features I just don't want to miss, and it's already available for nearly a year. I just don't want to work without the
"NativeActivity"-class and without the ability to use EGL within the native application. Especially EGL would be a nasty one because one code would have to run in a
Java wrapper class (EGL initialization, page flip) while all the rest would be done within the native application. To be honest, I don't like Java much, and I don't
want to write too much special Android-only codes... my spare time is limited and I don't want to waste it by trying to support out-of-date Android versions. Read e.g.
http://blogs.arm.com/software-enablement/366-android-23-gingerbread-ndk-now-close-to-pure-native-development/ for more information about this topic. By the way, another
nice feature is OpenSLES for sound... so, Android 2.3 it is.
>> 14.08.2011
[CO]
- Started support for MS Windows x64. To be able to continue the development of PixelLight with x86 & x64 at the same time without any effort, all binaries will now be
within x86/x64 subdirectories. The plugin subdirectories within the runtime directory are going to be removed, this approach is just causing to many issues across
multiple platforms. Everything runtime related will now be within the runtime root directory (in x86 & x64 subdirectories).
>> 13.08.2011
[CO]
- Frontend refactoring related configuration cleanup
>> 03.08.2011
[CO]
- Naming cleanup: "Window" can have many meanings (OS window? PLGui window? etc.) - so made it clear when "Window" is a "system native window handle" to avoid confusion
>> 31.07.2011
[CO]
- "PixelLight/PixelLight.cmake": VisualStudio 2010 files are only copied into the SDK on the MS Windows platform
>> 28.07.2011
[CO]
- Now using the new language keyword "override" from C++0x in order to give the compiler a chance to detect and blame more errors related to overwriting methods.
See PLCore diary entry "27.07.2011" for details.
- When using the CMake 2.8.5 I received the following warning
CMake Warning at C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/CPack.cmake:236 (MESSAGE):
CPack.cmake has already been included!!
Call Stack (most recent call first):
Packages/Pack-Runtime.cmake:100 (include)
Packages/CMakeLists.txt:23 (include)
-> When removing "#include(CPack)" from "Pack-Docs.cmake", "Pack-Runtime.cmake" and "Pack-SDK.cmake" the warning disappears, but building the SDK by using MS
Windows and VisualStudio 2010 will fail
>> 18.07.2011
[CO]
- Documents: Noticed that within the runtime directory it's named "Doc" while it's called "Docs" in other places. Renamed "Doc" into "Docs".
>> 17.07.2011
[CO]
- I noticed multiple times that over the years an inconsistency in the general naming structure has been introduced. Right at the beginning of the development
we put a "PL" in front of structure directories. Over the time some directories without "PL" were introduced, like "External" instead of "PLExternal". Further,
while there was e.g. a directory called "PLBase", the CMake project within this directory was named "project(Base)". That's somewhat confusing.
So I decided to remove the "PL" in front of the structure directories (within the resulting SDK there were no such prefixes as well).
-> "PLBase"->"Base", "PLDocs"->"Docs", "PLPlugins"->"Plugins", "PLSamples"->"Samples", "PLTools"->"Tools", "PLTests"->"Tests", "PLRuntime"->"Runtime"
>> 14.07.2011
[CO]
- Moved PLGui, PLInput, PLRenderer, PLMesh, PLScene, PLPhysics, PLSound and PLEngine into the PLBase directory
-> Until now, the PixelLight base projects were split up into the three different directories "PLBase", "PLGui" and "PLEngine" and it
was not always clear to me why e.g. "PLGraphics" is a "PLBase"-project while "PLInput" or "PLRenderer" is a "PLEngine"-project altought they
are basic stuff as well. To simplify the structure of the Git repository, I moved the "PLGui"- and "PLEngine"-projects into the "PLBase"-directory
because those project indeed form together the base of PixelLight (no change within the resulting build SDK). Everything else is just optional
pluggin-in and therefore within the "PLPlugin"-directory. Those two distinctions should do the trick.
>> 12.07.2011
[CO]
- Moved PLInstall into the tools directory
- Moved PLUpgrade into the tools directory
- Moved "sfk" from the "PLSDK"-directory into the "cmake"-directory (used by "cmake\Modules\FindSFK.cmake")
- Moved "diff" from the "PLSDK"-directory into the "cmake"-directory (used by "cmake\Modules\FindDiff.cmake")
- Moved "VisualStudio"-directory from the "PLSDK"-directory into the "PLTools"-directory
- Moved "FindPixelLight.cmake"-directory from the "PLSDK"-directory into the "PLTools"-directory, this file is now also
copied into the PL SDK
- Moved this diary from "Diary.txt" into the root directory... this diary was always used for general stuff which didn't fit
into any other per project diary, so, it's probably right in the root directory...
- Removed "PLSDK"... it's getting really full within the root directory and it's not always clear to me why there are certain detail
splits so that CMake stuff or general tools are distributed all over the Git repository.
- Updated out-of-date Microsoft HTML Help Compiler (hhc.exe) related information
/*********************************************************\
* The entries below are in German only
\*********************************************************/
>> 15.08.2010
[SB]
- Neues Script 'profile' hinzugefügt, welches unter Linux die Umgebungsvariable
PL_RUNTIME setzt. Bitte Kommentare im Script beachten (nicht ausführen mit
z.B. "./profile", sondern in aktueller Shell einbinden mit ". ./profile").
- CMake-Scripte: Alle plugins können nun einzeln über eine CMake-Options ein- oder ausgeschaltet werden. Ich habe allerdings
darauf verzichtet, diese auch noch alle ins maketool einzubauen, dies muss man dann also per Hand z.B. durch Editieren
von CMakeCache.txt verwenden. Per default sind alle Plugins eingeschaltet, es sei denn es wird 'minimal' verwendet, dann
werden per Default nur die wichtigsten Plugins gebaut und alle anderen ausgeschaltet. Ebenso gibt es noch ein weiteres Flag,
um speziell für mobile Geräte zu bauen. Dies kann im maketool per "--mobile" aktiviert werden und sorgt momentan nur
dafür, dass anstelle des OpenGL-Plugins das OpenGLES-Plugin verwendet wird (hier könnten aber z.B. noch weitere Projekte
ausgeschlossen werden, die sich momentan noch nicht für mobile Geräte bauen lassen).
>> 29.07.2010
[CO]
- Im "UsedTools"-Verzeichnis liegen nur noch Programme die man unmittelbar so in dieser Form zum Bauen des SDKs
mit CMake benötigt. Alles andere, was man erst richtig Installieren muss entfernt. In "Readme.txt" steht weiterhin
mit welchen Versionen wir arbeiten bzw. mit welchen Versionen wir das zum letzten mal getestet haben so das man weis
was auf jedenfall gehen sollte. Diese ganzen Installierbaren Tools ständig aktuell zu halten macht einfach nur Arbeit
und das Repository wird durch diese größeren Dateien nur künstlich aufgebläht - und am Ende arbeitet eh wieder jeder
mit einer anderen Version (was im Grunde auch ok ist)...
>> 08.07.2010
[SB]
- Freetype in External2 hinzugefügt.
>> 01.06.2010
[CO]
SDK Installer:
- Statt "AddToPath" wird nun das aktuellere "EnvVarUpdate" verwendet:
http://nsis.sourceforge.net/Environmental_Variables:_append%2C_prepend%2C_and_remove_entries#Function_Code
- Dem SDK liegt nun "Microsoft Visual C++ 2008 SP1 Redistributable Package" bei damit im SDK was aktuelles ist
http://nsis.sourceforge.net/VC_8.0_Redistributables
- Es wird nun ähnlich wie bei http://nsis.sourceforge.net/VC_8.0_Redistributables anhand von Uninstall Keys
geprüft ob VC 2008 Runtimes da sind. Nun klappt der Test auch bei meiner Windows 7 64 Bit Version wo ich
bisher immer direkt vom PL SDK Installer die Meldung bekam ich müsse Redistributables installieren, obwohl
diese bereits in Masse da waren. (gib ja leider zig Versionen der Runtime)
Ich habe hier mal unter Windows XP und Windows 7 alle Runtimes deinstalliert und verschiedene Kombinationen
ausprobiert - die Erkennung ob die VC Runtime installiert ist, scheint nun ganz ordentlich zu funktionieren.
Da ich auch eine Abfrage auf "Visual C++ 2008 x86 Runtime - (v9.0.30729)" eingebaut habe, kann ich auch alle
VC Runtimes deinstallieren, da ich aber die VC Entwicklungsumgebung habe, hab ich trotzdem alles nötige und
der PL SDK Installer erkennt das nun. :D
- Es wird nun "RequestExecutionLevel highest" gesetzt damit Windows UAC weis woran es ist und nicht in irgendeinen
Problematischen Fallbackmodus fallen muss. "RequestExecutionLevel user" reicht leider nicht da wir was an der Registry
ändern - nur bei diesem Modus ist man beim PL SDK Installer starten aufpoppenden UAC Warn Dialog befreit.
- In der PL SDK Installer befinden sich nun auch noch ein paar allgemeine Detail Infos (File Properties)
>> 15.03.2010
[CO]
- Aktuelle Versionen von Doxygen, graphviz, CMake und NSis eingeladen + getestet, geht alles
>> 11.07.2009
[CO]
- "UsedTools": "svn-win32-1.5.0.zip" durch "Slik-Subversion-1.6.3-win32.msi" ersetzt das man einfach nur zu installieren
braucht ohne das man z.B. per Hand noch Pfad Variablen anpassen muss
>> 20.06.2009
[SB]
- CMake: PL_EXTERNAL_CONFIGURE() für's Cross-Compiling fit gemacht. Wird eine Toolchain benutzt, werden die übergebenen
Pfade nun automatisch auch an ein configure-Script übergeben, so dass das entsprechende Projekt ebenfalls cross-compiliert
wird.
- CMake: Die Toolchain-Datei wird nun ebenfalls bei jedem External-Script am Anfang einmal aufgeführt, damit die dort definierten
Variablen alle automatisch auch in den External-Scripten zur Verfügung stehen.
- CMake: In allen Projekten -march=i686 entfernt, da dies natürlich beim Crosscompilieren für andere Architekturen nicht mehr
stimmt.
- CMake: Über die Variable NO_INLINE_ASM wird festgelegt, ob im Programm inline-assembler erlaubt ist, oder nicht. Wird
diese Variable gesetzt, was überlicher Weise in einer Toolchain-Datei passiert, übergibt CMake eine gleichnamige Definition
(NO_INLINE_ASM) an den Compiler, welche im Code über #ifdef abgefragt werden kann. Dies ist notwendig, damit ein
Cross-Compilieren für andere (nicht x86) Architekturen möglich ist. An allen Stellen, wo Inline-Assembler eingesetzt wird,
muss also nun mittels #ifdef diese Option abgefragt werden und immer ein Fallback in C++ hinzugefügt werden, das benutzt wird,
sobald NO_INLINE_ASM gesetzt wurde.
>> 19.06.2009
[SB]
- CMake: Beim patch von TinyXML fehlte wohl noch eine spätere Änderung. Diese hinzugefügt und Patch aktualisiert.
- CMake: libpng übersetzt nun keine eigene zlib mehr, sondern versucht, die bereits als eigenes External-Projekt vorhandene
zlib zu verwenden.
- PLGeneral auf Verwendung der neuen Externals umgestellt.
- PLGraphics auf Verwendung der neuen Externals umgestellt.
>> 18.06.2009
[SB]
- CMake: Die External-Scripte haben nun einen Mechanismus, der dafür sorgt, dass eine Aufgabe auch nur noch einmal ausgeführt
wird, und nicht jedesmal, wenn das Script aufgerufen wird. Wenn also z.B. das 'Configure' für ein External-Projekt einmal
korrekt durchgelaufen ist, wird es nicht noch einmal wiederholt. Zusätzlich sind die Abhängigkeiten so gewählt, dass
ein Script, das neu ausgeführt wird, auch alle nachfolgenden Scripte erneut ausführen lässt. Beispiel: Wenn 'Configure'
neu ausgeführt werden musste, werden automatisch auch 'Build' und 'Install' ausgeführt, weil diese von 'Configure' abhängig
sind. Als weitere Abhängigkeit ist jedes External-Script von sich selbst abhängig. Wenn also z.B. die Datei ExternalFetch.cmake
verändert wird, führt dies automatisch dazu, dass beim nächsten Build das Target 'Fetch' erneut ausgeführt wird (und
danach alle weiteren Aufgaben dieses Externals, da 'Fetch' am Anfang der Kette steht). Dieses Verhalten dürfte nun so sein,
wie man es von Projekten generell erwartet. Nachdem die Externals alle einmal erfolgreich gebaut wurden, dürften nun also
alle Projekte als 'aktuell' gelten und nicht mehr neu ausgeführt werden, solange bis sich irgend etwas an den External-Scripten
ändert.
- CMake: Die External-Scripte definieren nun Variablen für das Einbinden der erstellten Bibliotheken, z.B. TINYXML_INCLUDE_DIR
und TINYXML_LIBRARIES. Diese können in den Projekten verwendet werden, in denen diese Bibliotheken verwendet werden, wodurch
automatisch die richtige Datei und Version verwendet werden sollte. Damit dürfte einiges an IF/ELSE aus den Projekten
verschwinden, da dies nun bereits im jeweiligen External-Projekt erledigt wurde. Ein Projekt sollte zusätzlich eine
Dependency zu dem External-Projekt definieren, dessen libraries es verwendet, damit dies automatisch gebaut wird, bevor
das abhängige Projekt gebaut werden soll. Damit müsste wieder alles vollautomatisch funktionieren, und man muss eigentlich
nur einmal "Make" bzw. "Build Project" ausführen, damit alles nacheinander erstellt wird :-)
>> 17.06.2009
[SB]
- CMake: Target 'Clean' bei den Externals hinzugefügt, also z.B. "zlib-Clean" aufrufen, um alle erstellten Dateien
von zlib zu löschen.
- CMake: Target 'Externals-Clean' ruft die Clean-Targets aller External-Projekte auf.
- CMake: Textausgaben für alle wichtigen Kommandos bei den Externals hinzugefügt. Auf der Ausgabe werden nun nur noch diese
Meldungen angezeigt, die Compilerausgaben, Fehlermeldungen etc. landen statt dessen in einer Logdatei (z.B. 'Build.log',
'Configure.log' etc.). Damit kann man dem bauen der externen Bibliotheken besser zusehen, als wenn da ewig lange Ausgaben
herunterscrollen, die man gar nicht mehr verfolgen kann und die einen eigentlich auch nicht interessieren. Man braucht
diese Ausgaben eigentlich nur im Fehlerfall, daher werden sie in den genannten Logdateien gespeichert.
>> 15.06.2009
[SB]
- CMake: Habe einen ersten Versuch eingebaut, die Bibliotheken in "External" automatisiert herunterzuladen und zu übersetzen.
Dafür habe ich einige CMake-Scripte geschrieben, die es erlauben, externe Projekte herunterzuladen, zu konfigurieren
und schliesslich zu bauen. Mithilfe dieser Makros können dann Scripte für jede externe Abhängigkeit geschrieben werden,
was ich für External/Base bereits getan habe. Je nachdem, unter welchem System gebaut wird, werden dann die entsprechenden
Tools dieses Systems eingesetzt, so dass das Übersetzen unter allen Systemen und Generatoren funktionieren sollte.
Diese Scripte sollten es für uns einfacher machen, externe Abhängigkeiten zu verwalten und zu pflegen, da wir nicht mehr
alles per Hand bauen müssen. Mit etwas Glück wird ein einmal geschriebenes Script längere Zeit für eine externe Bibliothek
funktionieren, solange sich in dem Projekt nicht das Buildsystem ändert. Dadurch dürfte es für uns deutlich einfacher sein,
aktuelle Versionen einer Bibliothek einzuspielen. Auch das Übersetzen unter verschiedenen Systemen sollte damit deutlich
weniger Arbeit machen, da dies nun automatisiert passiert. Gerade, wenn wir demnächst auch für andere Systeme und
Hardwareplattformen übersetzen wollen, wäre ein manuelles Übersetzen aller externen Biblbiotheken für jeweils alle
Plattformen und Betriebssysteme nicht mehr praktikabel.
>> 13.06.2009
[SB]
- CMake: Toolchain-Support eingebaut. Dies wird normaler Weise nicht verwendet, nur wenn man das Projekt cross-compilieren will,
wird dies benötigt. In diesem Fall kann man dem buildtool-script die Option "--toolchain <name>" übergeben, und dann wird
das entsprechende Toolchain-File aus dem Verzeichnis cmake/Toolchains/ gelesen. Wie gesagt ist dies nur für's Cross-Compiling,
solange man nur auf seinem lokalen System für dasselbe System übersetzen will hat sich aber nichts geändert.
>> 03.06.2009
[CO]
- "PLInstall" arbeitet nun mit Unicode
- "PLInstall": Ich fand gerade ENDLICH nach längerem Recherieren heraus wie Änderungen an der PATH Umgebungsvariable
sofort korrekt übernommen werden OHNE das man sein System neustarten muss was ein totales unding ist... "broadcast"
heist der Trick. Man muss einen "broadcast" abfeuern um bescheitzugeben das sich an der Registry etwas änderte - danach
werden dlls sofort gefunden OHNE das man das System neustarten musste. Endlich. :D
>> 10.05.2009
[CO]
- "PLInstall": Unter Windows Vista und Windows 7 ist üblicherweise noch keine "PATH"-Variable da und dann schlug das setzen fehlt. Daher wird hier
nun automatisch in dem Fall eine solche Variable hinzugefügt.
- "PLInstall": VC-Projekt Einstellung "Linker" -> "Manifest File" -> "UAC Execution Level" von "asInvoker" in "requireAdministrator" geändert.
Dies ist unter Windows Vista und Windows 7 nötig damit man "HKEY_LOCAL_MACHINE" verändern kann, ansonnsten wird der Zugriff verweigert.
-> Nun funktioniert das hilfreiche "PLInstall.exe" auch auf den neuen Windows Versionen :D
>> 16.04.2008
[SB]
- CMake: Beim Linken der Libraries werden statische Bibliotheken nun nicht mehr "transitiv" auch zu den davon abhängigen Projekten hinzugefügt. Bisher
war es so, dass wenn DynLibA die statischen Bibliotheken Lib1 und Lib2 verwendete, und App1 wiederum von DynLibA abhängig war, dann automatisch auch
App1 selbst gegen Lib1 und Lib2 gelinkt wurde. Dies war ja ganz am Anfang, als ich das CMake Build-System einführte, schon ein kleiner Streitpunkt, damals
bot CMake allerdings noch keine Möglichkeit, dieses Verhalten zu unterbinden, und auch wenn es unnötig war, gab es damit ja keinerlei Probleme :-)
Da CMake dieses Möglichkeit aber inzwischen bietet, wird dieses Verhalten nun in unseren Projekten standardmäßig abgeschaltet. Dadurch sollten die erstellten
Bibliotheken und Applikationen etwas kleiner werden. Durch diese Änderung fiel auch an einer Stelle auf, wo die Reihenfolge der Bibliotheken unter Linux
noch falsch war.
>> 07.02.2008
[CO]
- Fügte im SDK wie besprochen einen "VC2008_Redistributable"-Ordner hinzu in dem "Microsoft.VC90.CRT.manifest", "msvcp90.dll" und "msvcr90.dll"
liegen (ich hoffe da kommen nicht irgendwann noch ähnliche Dinge hinzu... dann müsste man sich überlegen ob man das anderst Strukturieren will)
>> 24.12.2008
[CO]
- Im SDK Start-Menü befindet sich nun auch ein Eintrag zur PixelLight Website... kam regelmäßig vor das man nach der Addresse gefragt
wurde obwohl diese auch z.B. in 'SDKBrowser.chm' steht... wir wollen es den Leuten ja so einfach wie möglich machen. *säufts*
- "ReleaseNotes.txt" dem SDK hinzugefügt + Eintrag ins SDK Start-Menüs damit man auch Offline nochmal die Hauptänderungen nachlesen kann
- NSIS: Aktuelle Version "2.42" eingespielt
- CMake: Aktuelle Version "2.6.2" eingespielt
- Doxygen: Aktuelle Version "1.5.7.1" eingespielt
- Der PixelLight SDK Installer prüft nun vor dem Installieren ob bereits eine PixelLight SDK Version installiert ist - wenn ja, so wird
man gefragt ob man vor dem Installieren die alte Version deinstallieren möchte. War einfacher und viel schneller realisiert als ich dachte. :)
>> 11.12.2008
[CO]
- "NSIS.template.in": Fallunterscheidung für 3ds Max 2008/2009 - man darf nicht beide Exporter in z.B. das
3ds Max 2008 Verzeichniss kopieren da sonst 3ds Max 2008 meckert das es das Plugin für 3ds Max 2009 nicht
laden kann. (was auch nachvollziehbar ist :)
Muss das noch austesten - der Registry Eintrag müsste aber korrekt sein. (hab das hier gerade nachgeprüft)
>> 06.12.2008
[CO]
- Mit "PixelLightWizard" für Visual Studio angefangen.
-> "http://www.codeguru.com/cpp/v-s/devstudio_macros/customappwizards/article.php/c12775__1/"
ist ein recht brauchbares Tutorial wie man soetwas angeht. :D
Beim übersetzen wird der Wizard standardmäßig automatisch nach z.B. "C:\Dokumente und Einstellungen\COfenberg\Eigene Dateien\Visual Studio 2008"
kopiert. ("PixelLightWizard.ico", "PixelLightWizard.vsdir", "PixelLightWizard.vsz")
>> 13.09.2008
[CO]
- Die 64 Bit VC Projekte nutzen nun die 32 Bit Version von PLProject damit die Projekte sich auch problemlos unter einem 32 Bit
System übersetzen lassen
>> 07.09.2008
[CO]
- 'pak' in 'zip' umbenannt damit das nicht mehr verwirrt und es gibt nicht wirklich einen Grund für eine solche Umbenennung
>> 31.08.2008
[SB]
- CMake: Möglichkeit eingebaut, um Dateinamen und Target-Namen unterschiedlich zu vergeben. Damit kann z.B. "nppl3d.dll"
erstellt werden und trotzdem "PLPluginMozilla" als Target-Namen beibehalten werden.
- CMake: Makros für MIDL eingebaut, damit man auch ActiveX-Projekte mit CMake bauen kann. Da ich keinen eingebauten Support
bei CMake finden konnte (oder dieser nur mit dem VC-Generator funktioniert), habe ich daher ein eigenes Makro geschrieben.
Das ist sicherlich noch nicht perfekt, aber ich konnte damit unser ActiveX-Control erfolgreich übersetzen :-)
>> 18.08.2008
[SB]
- ReleaseNotes.txt hinzugefügt. Diese Datei wird beim Release veröffentlicht, daher sollten wir uns hier kurzfassen und nur die
für den User wirklich wichtigen Änderungen auflisten. Ich stelle mir das ungefähr so vor (von CMake abgeschaut, später finden
wir bestimmt noch unseren eigenen Stil):
Changes in PixelLight x.y.z RCn
- Fix bug XXXX Bug Title
- Improvement:
- Feature:
- Updated library abc to xyz
- Or another small sentence about what you did
Ich werde also bspw. nicht hineinschreiben, wenn ich mal wieder alles unter Linux übersetzt habe oder ähnliches - nur Bugs/
Erweiterungen, die auch wirklich sichtbar sind. Behobene Bugs sollten natürlich rein, aber ruhig recht kurz und falls möglich
zusammenhängende Bugs sortieren. Alles weitere finden wir in nächster Zeit einfach heraus :-)
>> 17.08.2008
[SB]
- Damit sich die Dateien vernünftig sortieren lassen (alle zu einer Version gehörigen Dateien hintereinander), kommt nun die
Versionsnummer im Namen zuerst, danach das Paket (z.B. "PixelLight-0.8.0-SDK.exe").
- Neues Paket 'Docs' für die Dokumentation hinzugefügt.
- Neues Target 'Upload': Mittels "make Upload" können die erstellten Pakete damit automatisch per SCP auf unseren Server geladen
werden. Dies kann natürlich nur funktionieren, solange der gefundene SCP-Client es irgendwie hinbekommt, den richtigen
Benutzernamen und SSH-Key zu übermitteln. Unter cygwin und Linux sollte dies kein Problem sein, da hier als Benutzername der
aktuell aktive Benutzer genommen wird und der Key in dessen Home-Verzeichnis. Mit Putty/Windows könnte das schwieriger sein,
hier kommt es vermutlich darauf an, wie die Session gespeichert wurde - da der Benutzername nicht festgelegt werden kann,
müßte wohl der Name der Session "pixel-light.de" sein und den entsprechenden Benutzernamen und Key spefizifieren.
Erfahrungsberichte sind immer willkommen :-)
>> 04.08.2008
[CO]
- Verschob die Lizenz-Texte von 'PLDocs/License' in den PixelLight Grundordner und fügte eine Text-Datei Namens 'COPYING' hinzu.
Eine Datei mit so einem Namen ist sehr verbreitet, normalerweise steht dort der 'gesammte' Lizenz-Text - das wollte ich aber
nicht da ich das irgendwie unhandlich finde. Daher steht in 'COPYING' unser 'Standard Lizenz Text' der auch im SDKBrowser und
auf unsere Homepage steht + verweise in welchen Dateien welcher Lizenz-Text zu finden ist. Ich denke das ist ein ordentlicher
Kompromiss und von z.B. aus dem SDKBrowser kann man weiterhin komfortabel direkt auf die einzelnen Lizenz-Texte verlinken.
>> 10.07.2008
[SB]
- Habe mich mal etwas genauer mit NSIS beschäftigt und das Install-Script unseren Bedürfnissen angepasst. Es ist tatsächlich
nicht so schwer, auch wenn die Scriptsprache ziemlich low-level ist und daher etwas fummelig ist. Aber mit etwas Ausprobieren
und Dokus anschauen ist das recht leicht zu machen. Etwas kniffelig war die Anbindung an CMake, da hier natürlich auch einige
Variablen und Dateien übergeben werden müssen, das ist aber nun gelöst (siehe Pack-Scripte). Unser Installer ist nun um
folgende Features reicher:
- Der Exporter kann automatisch ins 3DMax-Verzeichnis kopiert werden
- Dateiformate für PixelLight (im Moment nur .scene) können automatisch bei Windows registriert werden. Das ist leider mal wieder
unnötig kompliziert, denn es reicht offenbar nicht mehr aus, wie früher die Dateiverküpfung unter HKEY_CLASSES_ROOT einzutragen.
Offenbar speichert der Explorer zusätzlich nochmal die aktuelle Verknüpfung, daher lösche ich diesen Key einfach, falls er
vorhanden ist.
- Der SDK-Browser kann automatisch geöffnet werden.
- Nach dem Installieren wird automatisch PLUpgrade.exe gestartet, wo wir immer die aktuell nötigen Checks und Workarounds
einbauen, damit es möglichst keine Probleme beim Installieren von PL gibt.
- VCRedist.exe ist jetzt direkt im Installer enthalten und wird automatisch ausgeführt, wenn die Runtime auf dem Rechner noch
nicht installiert ist. Leider konnte ich hier keinen zuverlässigen Test finden, ich hoffe daher, dass es so funktioniert,
wie ich es jetzt eingebaut habe (es wird geschaut, ob ein bestimmtest Verzeichnis vorhanden ist).
>> 08.07.2008
[SB]
- Alle Plugin-Projekte auf die Verwendung von PLProject umgestellt. Dadurch werden die plugin-Dateien nun automatisch aus
den Quellen und den darin enthaltenen RTTI-Makros erzeugt. Dadurch muss nun einiges weniger angepasst werden :-)
PLProject wird in den CMake-Scripten sowie in den VC-Projekten als Post-Build Event ausgeführt, und bisher konnte ich
keinerlei Probleme auch bei einem kompletten Rebuild feststellen.
>> 07.07.2008
[SB]
- CMake-Tools: Einige Ausgaben hinzufügt, wo diese nicht automatisch vom entsprechenden Modul generiert werden, z.B. beim Suchen
von Latex, Subversion etc. Es sollte wirklich jedes Programm, das benutzt wird, bei der Ausgabe auftauchen, damit man dann schnell
feststellen kann, ob ein benötigtes Programm fehlt. Ausserdem die Makros etwas geändert, so dass die CMake-Projekte auch dann
ohne Fehlermeldung durchlaufen, wenn LaTeX nicht installiert ist - dann fehlen einfach nur die entsprechenden Dokumentationen.
Allerdings geht dies im Moment noch schief, da die PostBuild-Kommandos immernoch versuchen, die (nicht erzeugte) PDF-Datei zu kopieren.
>> 21.06.2008
[SB]
- Neuer Ordner "PixelLight" mit einer Include-Datei "PixelLight.h" hinzugefügt. In dieser Datei stehen
Informationen über die Konfiguration von PixelLight, z.B. die aktuelle Version und das verwendete Suffix.
Nur wenige Projekte (z.B. PLCore) sollten diese Datei direkt einbinden müssen, die anderen greifen auf
globale Funktionen zurück, um die benötigten Infos abzufragen. Beispielsweise wird dies verwendet, um
den Namen des Registry-Keys herauszubekommen, der vom aktuell verwendeten Suffix abhängt.
- CMake: Die Datei PixelLight.h wird in CMake automatisch aus PixelLight.h.in erzeugt und muß daher anstelle
der statischen PixelLight.h im Repository verwendet werden. Darum wird in den entsprechenden Projekten
nicht PixelLight/ als Include-Verzeichnis verwendet, sondern das aktuelle Ausgabeverzeichnis, in dem die
Datei PixelLight.h erzeugt wurde.
- PLInstall: Bindet PixelLight.h ein und verwendet das dort angegebene Suffix.
- Installer: Der verwendete Registry-Key hängt nun vom angegebenen Suffix ab, dadurch müßten zwei Installation
von PixelLight mit unterschiedlichem Suffix nun komplett unabhängig voneinander sein und auch nicht mehr
Plugins von der jeweils anderen Version laden.
>> 20.06.2008
[SB]
- PixelLight.cmake ins Root-Verzeichnis verschoben.
- PixelLight.cmake beinhaltet nun alle wichtigen Einstellungen für das Erstellen eines Builds.
Beim Aufruf von CMake, z.B. über das Windows-Gui, lassen sich folgende Einstellungen vornehmen:
- PL_PROJECT_RELEASE: Sollte auf 'true' gesetzt werden, wenn man vorhat, ein PixelLight-Release oder einen
Nightly-Build zu erstellen. Ansonsten 'false' für die lokale Entwicklungsversion
- PL_PROJECT_RELEASE_NIGHTLY: 'true' für Nightly-Builds (verändert nur die Benennung von Paketen, da kommt dann noch
wie bisher die Revision-Nummer hinein, die bei Releases nicht mehr dazugeschrieben wird)
- PL_PROJECT_SUFFIX_RELEASE: Suffix der benutzt wird, wenn PL_PROJECT_RELEASE auf 'true' steht
- PL_PROJECT_SUFFIX_DEVELOPMENT: Suffix der benutzt wird, wenn PL_PROJECT_RELEASE auf false' steht
Diese Variablen werden im Cache gespeichert und überschreiben damit die Standardwerte aus der PixelLight.cmake, daher
sollten diese Werte nur innerhalb des CMake-Gui geändert werden und nicht durch Ändern der Datei (es sei denn natürlich,
man möchte die Standardwerte verändern). Die Versionsnummer ist dagegen keine Cache-Variable, da diese ja nicht pro
Build geändert werden sollte sondern zur aktuellen Source-Version gehört. Das wird daher in der Datei verändert und
ins Repository hochgeladen, wie normale Sourcecode-Veränderungen auch.
- CMAKE_BUILD_TYPE wird nun standardmäßig auf "Release" gesetzt, nicht mehr auf Debug. Das macht das bauen von Release-Paketen
noch ein wenig leichter, nur wenn man seine lokale Development-Version mit CMake bauen will, muss man das am Anfang
ggf. auf Debug setzen. Und da ich selber immer auf der Kommandozeile arbeite, kann ich das dort auch entsprechend scripten.
- Noch folgende Überprüfungen eingebaut:
- Nur wenn PL_PROJECT_RELEASE gesetzt ist, lassen sich die Installationspakete bauen
- Nur wenn PL_PROJECT_RELEASE und PL_PROJECT_RELEASE_NIGHTLY gesetzt sind, lassen ich die Nightly-Targets ausführen
- Wenn PL_PROJECT_RELEASE gesetzt ist aber gleichzeitig CMAKE_BUILD_TYPE auf 'Debug' steht, bricht cmake mit einer
Fehlermeldung ab, da ich nicht denke, dass Debug-Pakete sinnvoll sind.
- Das 'maketool' angepasst, damit das wieder genauso komfortabel ist wie die Erstellung über das CMake Gui :-)
>> 19.06.2008
[SB]
- Variablen umbenannt, damit das einheitlich ist: PROJECT_OUTPUT_DIR -> PROJECT_TARGET_OUTPUT_DIR
und PROJECT_OUTPUT_NAME -> PROJECT_TARGET_OUTPUT_NAME.
- In PL_PROJECT zusätzliche Variablen hinzugefügt für die statische Version einer Bibliothek: PROJECT_TARGET_STAT,
PROJECT_TARGET_STAT_OUTPUT_DIR, PROJECT_TARGET_STAT_OUTPUT_NAME und PROJECT_TARGET_STAT_STATIC_LIB
- PL_SET_PROPERTIES um ein Flag "STAT" erweitert. Wird dieses angegeben, so wird die statische Version des
Projektes benutzt.
- Bei dem Versuch, gleichzeitig eine dynamische und eine statische Version von PLGeneral zu erzeugen, mußte ich
feststellen, dass ADD_DEFINITIONS hier Probleme macht. Anscheinend wird nicht der aktuelle Wert der Definitionen
zu dem Zeitpunkt benutzt, wenn man z.B. ADD_LIBRARY aufruft, sondern anscheinend wird immer der Wert benutzt, den
ADD_DEFINITIONS am Ende der Abarbeitung der CMakeLists.txt hat. Damit ist es natürlich nicht möglich, so etwas
zu machen:
ADD_DEFINITIONS(...)
ADD_LIBRARY(PLGeneral SHARED ...)
REMOVE_DEFINITIONS(-D_USRDLL -D_WINDLL -DPLGENERAL_EXPORTS)
ADD_DEFINITIONS(-DPLGENERAL_STATIC)
ADD_LIBRARY(PLGeneral_stat STATIC ...)
Deswegen mußte ich nun auch für ADD_DEFINITIONS eine eigene Version schreiben (ADD_COMPILE_DEFS), die genauso wie schon
bei den Compiler- und Linkerflags alles in einer Variable speichert und dann später in PL_SET_PROPERTIES den entsprechenden
Property (COMPILE_DEFINITIONS) des aktuellen Targets setzt. Das scheinen alles Überbleibsel aus alten Zeiten bei
CMake zu sein, die aber wegen Kompatibilität drin bleiben. Die neue Art scheint sowieso zu sein, alles über
Target-Properties zu setzen, von daher ist es auch gut, wenn wir das konsequent machen.
- Zwei (interne) Makros hinzugefügt: ADD_TO_LIST und REMOVE_FROM_LIST. Diese werden in den anderen Makros verwendet,
damit man nicht alles doppelt und dreifach machen muss.
- Zu allen ADD_-Makros ein entsprechendes REMOVE_-Makros hinzugefügt: REMOVE_SOURCES, REMOVE_LIBS, REMOVE_COMPILE_DEFS,
REMOVE_COMPILE_FLAGS, REMOVE_LINKER_FLAGS
- Es wird nun eine dynamische und eine statische Version von PLGeneral erzeugt. Mir ist allerdings noch nicht ganz klar,
warum die statische Version gleich 9MB (!) groß wird ...
- In allen Projekte ADD_DEFINITIONS durch ADD_COMPILE_DEFS ersetzt.
- ADD_DVI_DOCUMENT: Es werden nun die Optionen -quiet und -halt-on-error für LaTeX verwendet. Dadurch sollte keine
Tastatureingabe mehr erforderlich sein, wenn mal ein Fehler im Dokument ist, sondern einfach mit einem Fehler abgebrochen
werden. Dann kann zwar immernoch kein Paket gebaut werden, weil ja nicht alle Projekte fehlerfrei erzeugt werden konnten,
aber zumindest hält der Prozess nicht einfach an sondern geht mit einem Fehler zu Ende, wie es sein sollte. Hoffentlich
verhält sich das LaTeX unter Linux identisch ;-)
>> 17.06.2008
[SB]
- Zwei neue Makros hinzugefügt: ADD_SOURCES und ADD_LIBS. Mit diesen Makros werden die angegebenen Dateien den
Projekt-Sourcen oder Projekt-Libs hinzugefügt, also die entsprechende Variable erweitert. Damit ist die Verwendung
analog zu z.B. ADD_DEFINITIONS oder anderen CMake-Makros, in denen ebenfalls die übergebenen Werte hinzugefügt werden,
ohne dass die alten Werte überschrieben werden. Bisher konnte es leicht passieren, dass man beim Erweitern von z.B.
PROJECT_SOURCES oder PROJECT_LIBS vergisst, den vorherigen Inhalt der Variablen durch ${PROJECT_SOURCES} zu übernehmen,
dadurch wurde dann der Inhalt der Liste komplett überschrieben was zumeist zu merkwürdigen Fehlern beim Compilieren führt.
- Neues Makro: PL_SET_PROPERTIES. Setzt die Properties OUTPUT_NAME, COMPILE_FLAGS und LINK_FLAGS vom angegebenen Target
auf die PL-Variablen (z.B. PROJECT_OUTPUT_NAME). Da dies in jedem Projekt wieder das gleiche war, kann man auch das
noch verkürzen :-)
- DocTools.cmake hinzugefügt: Diese Datei enthält Makros für die typischen Dokumentations-Projekte, also z.B. für
LaTeX, Doxygen und HHC. Dadurch sehen die Docs-Projekte nun *sehr* übersichtlich aus :-)
- PLSDK/Packages nach cmake/Packages verschoben sowie einige Dateien umbenannt.
>> 16.06.2008
[SB]
- PROJECT entfernt und in PL_PROJECT aufgenommen.
- In allen CMake-Projekten den Aufbau so verändert, dass bei der Unterscheidung von Windows/Linux und Debug/Release möglichst
keine Wiederholungen mehr vorkommen. Alle Einstellungen, die gleich sind, werden daher jetzt als erstes gesetzt, danach
erst kommt wenn überhaupt noch nötig eine Fallunterscheidung. Das hat manche Dateien gleich um ca. 100 Zeilen verkürzt.
>> 15.06.2008
[SB]
- Verweise auf externe Libraries werden nun immer mit einem absoluten Pfad angegeben, wodurch keine
Library-Directories mehr angegeben werden müssen. Verweise auf andere PL-Projekte werden nur noch mit
dem Projektnamen, z.B. "PLGeneral" angegeben, nicht als Dateiname ("PLGeneralD.lib") und auch nicht mit
dem Debug-Flag ("PLGeneralD.lib" oder "PLGeneralD").
- Neue Targets für Projektgruppen hinzugefügt (z.B. PLGeneral).
- ADD_DEPENDENCIES werden nun so geschrieben, dass alle Abhängigkeiten in einer Zeile stehen. Dafür wird zusätzlich noch
die Abhängigkeit von der Projektgruppe hinzugefügt.
- Beim Build kann nun noch zusätzlich ein Suffix gesetzt werden, z.B. "sdk". Wenn das der Fall ist, wird bei allen
Bibliotheken dieses Suffix an den Dateinamen angehängt, z.B. "PLGeneral-sdk.dll", "PLGui-sdk.dll" etc. Das würde
es zumindest theoretisch ermöglichen, mehrere Versionen von PL gleichzeitig und unabhängig voneinander auf dem
gleichen PC zu installieren. Besonders interessant fände ich das, damit man immer ein aktuelles SDK installiert
haben kann und sich dieses nicht mit der lokalen Entwicklungsversion stört. Wie genau wir das nutzen müssen wir
aber mal sehen, im Moment wollte ich nur schonmal das Feature an sich implementieren :-)
- Neues Makro PL_PROJECT: Setzt den Namen des Projektes und einige wichtige Variablen, nämlich
PROJECT_TARGET, PROJECT_OUTPUT_NAME, PROJECT_TARGET_EXECUTABLE, PROJECT_TARGET_SHARED_LIB und PROJECT_TARGET_STATIC_LIB.
Ausserdem die Makros so verändert, dass der Name des Targets immer nur dem Projektnamen entspricht,
also z.B. "PLGeneral", während der Dateiname der Ausgabedatei z.B. "PLGeneralD-sdk" ist. Dadurch
kann ein Projekt immer einem unveränderlichen Namen referenziert werden, auch wenn der Dateiname
noch einige Suffixes oder andere Veränderungen enthält.
- PROJECT_TARGET_OUTPUT_DIR wird jetzt auch in PL_PROJECT gesetzt, da dies immer gleich ist und konnte somit aus den ganzen
Projekten entfernt werden.
- PROJECT_SRC und PROJECT_INC entfernt, da beide ziemlich überflüssig sind. PROJECT_SRC kann direkt durch den wirklichen
Pfad ersetzt werden, und PROJECT_INC wurde sowieso niemals benutzt.
- Für Pluginprojekte liegt jetzt die Beschreibungsdatei als .plugin.in im Projektverzeichnis. Während des CMake-Aufrufs wird
diese Datei nach Bin/ kopiert, wobei alle Dateinamen entsprechend der gewählten Konfiguration eingefügt werden, also z.B.
"PLSoundOpenAL-sdk.dll". Die "fertigen" .plugin-Dateien in Bin/ lasse ich erstmal drin, damit man weiterhin auch ohne CMake
arbeiten kann. So oft ändert sich da ja nichts, und das muss man zur Zeit dann eben doppelt anpassen. Man könnte sich überlegen,
das Kopieren/Konfigurieren dieser Dateien auch im VC-Projekt als Pre-Build-Step einzubauen.
>> 01.06.2008
[SB]
- CMake-Projekte überarbeitet und einige Fehler korrigiert. Es läßt sich nun auch unter Windows alles mit CMake übersetzen
und automatisch ein SDK packen. Es gibt noch einige kleinere Probleme mit den Compiler- und Linkerflags, diese fallen
jedoch zumindest mit Makefiles nicht ins Gewicht (mit VC-Projekten habe ich es noch nicht ausprobiert).
>> 05.04.2008
[SB]
- Habe einen neuen Ordner hinzugefügt, den wir für unsere Planungen nutzen sollten: "Plans". Hier schreibe ich nun hinein,
was mir alles so im Hinterkopf an Planungen zu bestimmten Themenbereichen herumschwirrt. In Todo-Listen kann man so etwas
nicht wirklich hineinbringen, da es einfach zu viel ist, dort alles zu erklären, und mit einem Stichpunkt (z.B.
"Application-Framework") kann man nicht erklären, was genau man sich darunter vorstellt. Alles per Mail etc. im Vorfeld zu
erklären fällt auch schwer und geht dann leicht verloren. Daher denke ich, dass eine solche Lösung sehr sinnvoll ist, so
kann man mal genau aufschreiben, wir man sich eine bestimmte Lösung vorstellt, so dass der andere auch eine Vorstellung
davon bekommt, wie das gemeint ist. Dann fällt es leichter, gemeinsam ab dieser Lösung zu arbeiten und natürlich die Idee
gemeinsam zu verändern und anzupassen. Das bringt dann mehr, als wenn dann einer warten muss, bis der andere seine Idee
umgesetzt hat. Wir sollten hier allerdings nur kurz- und mittelfristige Pläne reinstellen, damit es nicht zu viel wird,
50 Pläne in der Art "so könnte ich mir das ganz viel Später mal vorstellen" bringen uns sicherlich nichts ;-)
- Plan für "ApplicationFrameworks" hinzugefügt. So stelle ich mir das grobe Design von PixelLight vor, weg von den statischen
Instanzen in PLEngine und hin zu "Bausteinen", die man für konkrete Applikationen nutzen kann. Die Ansätze sind schon implementiert
und das klappt so auch schon recht gut, allerdings muss jetzt viel an der Engine umgebaut werden, um da weiter zu kommen.
- Plan für "InputHandler" hinzugefügt. Nach den Umbauarbeiten in PLEngine sollten wir versuchen, diese Lösung zu nutzen, um
auf Eingabegeräte zuzugreifen. Das dürfte recht schnell gehen, da es eigentlich nicht sehr kompliziert ist und würde sich
auch prima ins ApplicationFramework-Schema einfügen.
>> 02.03.2008
[CO]