[aspectc-user] Re: Symbian meet Aspect C++

Marti Bayo-alemany malemany at nero.com
Thu Sep 15 13:09:18 CEST 2005 

Hi Olaf,
Thanks for the help and sorry all Aspect user for instensively SPAMING the aspectC mailing list ;-)
After adding the -p option on the command line.
The command line looks like the following...
ac++ --no_line --skip-bodies-non-prj --no_problem_spec_scope --gnu-2.95 -D_DEBUG -D_UNICODE -D__SYMBIAN32__ -D__GCC32__ -D__EPOC32__ -D__MARM__ -D__MARM_ARMI__ -D__DLL__ -e cpp -c src-ah-in\NPlatformGUI_Symbian.cpp -o src-ah-out\NPlatformGUI_Symbian.cpp -p ..\..\..\SDK -p "..\Include" -p "..\..\..\nero_gui\GuiFileService" -p "..\..\Common" -p "..\..\Common\VideoOutputter" -p "..\..\FrameContatcher" -p "..\..\FrameContatcher\Util" -p "..\..\..\..\NeroHAL\include" -p "..\..\..\..\NeroHAL\include\inline" -p "..\..\..\..\GapiDraw35\include\Symbian" -p "..\..\..\..\GapiDraw35\include\Symbian" -p "..\..\..\core" -p "..\..\..\component_manager" -p "..\..\..\..\PerformanceLibs\helpers\armcpuid" -p "..\..\..\..\PerformanceLibs\ipp_wmmx" -p"..\..\..\..\PerformanceLibs\ipp_wmmx" -p"..\..\..\..\DecoderLibs\dm4v" -a aspects\aspect.ah -I\"C:\Symbian\7.0s\Series60_v20\Epoc32\include-aspects\" -I\"C:\Symbian\7.0s\Series60_v20\Epoc32\include-aspects\libc\" -I"..\Include" -I"..\..\..\nero_gui\GuiFileService" -I"..\..\Common" -I"..\..\Common\VideoOutputter" -I"..\..\..\SDK" -I"..\..\FrameContatcher" -I"..\..\FrameContatcher\Util" -I"..\..\..\..\NeroHAL\include" -I"..\..\..\..\NeroHAL\include\inline" -I"..\..\..\..\GapiDraw35\include\Symbian" -I"..\..\..\core" -I"..\..\..\component_manager" -I"..\..\..\..\PerformanceLibs\helpers\armcpuid" -I"..\..\..\..\PerformanceLibs\ipp_wmmx" -I"..\..\..\..\DecoderLibs\dm4v" -I"..\..\..\..\..\..\Symbian\7.0s\Series60_v20\Epoc32\include\mda\common\" -I"\epoc32\include" -I"\epoc32\include\libc" -p "..\..\..\..\NeroHAL\src\symbian"

I get now some errors like internal file is included by external file. 
For example that file ...
NeroHAL\src\symbian\os_threads_symbian.h ( called by ac++ as external)
...includes the file ...
NeroHAL\include\os_mutex (called by ac++ as internal)

Following there is the errors which I get...

Symbian\7.0s\Series60_v20\Epoc32\include\mda\common\" -I"\epoc32\include" -I"\epoc32\include\libc"
../../Common/../../SDK/../../NeroHAL/include/../src/symbian/os_mini_symbian.h:14: error: internal file '../../Common/../../SDK/../../NeroHAL/include/..
/src/symbian/../../include/inline/emu_int64.h' is included by external '../../Common/../../SDK/../../NeroHAL/include/../src/symbian/os_mini_symbian.h'
../../Common/../../SDK/../../NeroHAL/include/../src/symbian/os_types_symbian.h:39: error: internal file '../../Common/../../SDK/../../NeroHAL/include/.
./src/symbian/../../include/inline/emu_int64.h' is included by external '../../Common/../../SDK/../../NeroHAL/include/../src/symbian/os_types_symbian.h
'
../../Common/../../SDK/../../NeroHAL/include/../src/symbian/os_threads_symbian.h:5: error: internal file '../../../../NeroHAL/include/os_mutex.h' is in
cluded by external '../../Common/../../SDK/../../NeroHAL/include/../src/symbian/os_threads_symbian.h'
../../Common/../../SDK/../../NeroHAL/include/../src/symbian/os_files_symbian.h:4: error: internal file '../../Common/../../SDK/../../NeroHAL/include/st
dhelpers.h' is included by external '../../Common/../../SDK/../../NeroHAL/include/../src/symbian/os_files_symbian.h'

It seems it is complicated to set up aspect C++ for my concrete project. 
I would keep on with another solution using a perl script with some regular expresions. That should be enough to make a progress debugging.

best wishes,
Marti

----- Original Message ----- 
From: "Olaf Spinczyk" <Olaf.Spinczyk at informatik.uni-erlangen.de>
To: "Marti Bayo-alemany" <malemany at nero.com>
Cc: <fabian.scheler at gmail.com>; <aspectc-user at aspectc.org>
Sent: Thursday, September 15, 2005 11:40 AM
Subject: Re: [aspectc-user] Re: Symbian meet Aspect C++


> Hi Marti,
> 
> from looking at your STU command line, I conclude that my assumptions 
> was right: the problem is the -p option.
> 
> ac++ has the notion of a *project* and it distinguishes between files 
> that belong to the project, which is currently being transformed, and 
> file that do not. Only files of the project are manipulated!
> 
> The directories, which contain files that belong to the project, are 
> described with the -p option on the ac++ command line. If your source 
> code is distributed over multiple directory trees, you can provide *more 
> than one* -p option.
> 
> Note that -I options only tell the parser where it can find include 
> files. This is completely independent of the -p options.
> 
> In the WPT mode, which you prefer, you have to specify a destination 
> directory with the -d option for each project directory, i.e. -p <in> -d 
> <out> have to be used as pairs.
> 
> For example, if src-ah-in and "..\..\..\nero_gui\GuiFileService" belong 
> to your project, which means "should be transformed", you would have to 
> specify -p src-ah-in -d src-ah-out -p "..\..\..\nero_gui\GuiFileService" 
> -d "..\..\..\nero_gui\GuiFileService-out".
> 
> To summarize:
> 
> First find out, which files belong to your project and which do not. 
> Then use appropriate -p options with corresponding -d options on the WPT 
> command line. When you compile the generated code, make sure that the 
> compiler sees the transformed header files instead of the original 
> header files.
> 
> This should solve your problems.
> 
> Olaf
> 
> 
> Marti Bayo-alemany wrote:
>> Hi Olaf and Fabian,
>> 
>> I am feeling a little bit guilty for the record ,-)
>> 
>> That is my line ...
>> 
>> STU
>> ac++ --no_line --skip-bodies-non-prj --no_problem_spec_scope --gnu-2.95 
>> -D_DEBUG -D_UNICODE -D__SYMBIAN32__ -D__GCC32__ -D__EPOC32__ -D__MARM__ 
>> -D__MARM_ARMI__ -D__DLL__ -e cpp -c src-ah-in\NPlatformGUI_Symbian.cpp  
>> -o src-ah-out\NPlatformGUI_Symbian.cpp  -p .  -a aspects\aspect.ah 
>> -I\"C:\Symbian\7.0s\Series60_v20\Epoc32\include-aspects\"  
>> -I\"C:\Symbian\7.0s\Series60_v20\Epoc32\include-aspects\libc\" 
>> -I"..\Include" -I"..\..\..\nero_gui\GuiFileService" -I"..\..\Common" 
>> -I"..\..\Common\VideoOutputter" -I"..\..\..\SDK" 
>> -I"..\..\FrameContatcher" -I"..\..\FrameContatcher\Util" 
>> -I"..\..\..\..\NeroHAL\include" -I"..\..\..\..\NeroHAL\include\inline" 
>> -I"..\..\..\..\GapiDraw35\include\Symbian" -I"..\..\..\core" 
>> -I"..\..\..\component_manager" 
>> -I"..\..\..\..\PerformanceLibs\helpers\armcpuid" 
>> -I"..\..\..\..\PerformanceLibs\ipp_wmmx" 
>> -I"..\..\..\..\DecoderLibs\dm4v" 
>> -I"..\..\..\..\..\..\Symbian\7.0s\Series60_v20\Epoc32\include\mda\common\" 
>> -I"\epoc32\include" -I"\epoc32\include\libc"
>> 
>> I don't know how I should to change it in order to make it work.
>> The cpp files are in only one directory. The headers are splitted into a 
>> lot of different directories.
>> 
>> Best wishes
>> Marti
>> 
>> 
>> ----- Original Message ----- From: "Olaf Spinczyk" 
>> <Olaf.Spinczyk at informatik.uni-erlangen.de>
>> To: <fabian.scheler at gmail.com>
>> Cc: "Marti Bayo-alemany" <malemany at nero.com>; <aspectc-user at aspectc.org>
>> Sent: Thursday, September 15, 2005 9:25 AM
>> Subject: Re: [aspectc-user] Re: Symbian meet Aspect C++
>> 
>> 
>>> Hi,
>>>
>>> we just established a new record of postings per month ;-).
>>>
>>> Marti, you don't need the -i option. This is only needed by people who 
>>> use the STU mode to produce a library. In this special case, the 
>>> *.cc/cpp files are compiled with -c. The weaver expands the header 
>>> files that belong to the project (-p option(s)) automatically in the 
>>> generated *.cc/cpp files. Therefore, for the translation of the 
>>> library itself nothing else is needed. However, users who want to link 
>>> their applications with the library need transformed header files. In 
>>> order to provide these header files, the library developer has to use 
>>> the -i option, which transforms the header files of the project all at 
>>> once.
>>>
>>> The bug, which you have described, is strange, because the generation 
>>> of the declaration of the exec_old_... function is a quite fundamental 
>>> transformation, which definitely works.
>>>
>>> I guess that your header files are located in a different directory 
>>> than the *.cpp files and that you didn't use a -p <src> -d <dest> pair 
>>> for the header file directory. Therefore, ac++ doesn't *know* that 
>>> these files belong to your project and doesn't transform them.
>>>
>>> How does your directory structure (and your command line) look like?
>>>
>>> -Olaf
>>>
>>>
>>> Fabian Scheler wrote:
>>>> Hi Marti,
>>>>
>>>>> However what does it means other_stuff_you_need ?
>>>>> -i <other_stuff_you_need>
>>>>> Do you have to define all your include files behind the -i ?
>>>>
>>>> no, <other_stuff_you_need> has nothing to do with the option '-i',
>>>> <other_stuff_you_need> are just other options you may need for some
>>>> reason. I expressed this a bit awkwardly.
>>>>
>>>>> I am just wondering about that not because I need to do library. The 
>>>>> main
>>>>> reason is the error I am having ...
>>>>>
>>>>> ../SRC-AH-OUT/Guihelperclasses.cpp:1248: no `void
>>>>> NConfigDataGUI::__exec_old_SetEqualizerPresetSelection(long unsigned 
>>>>> int)'
>>>>>    member function declared in class `NConfigDataGUI'
>>>>>
>>>>> It makes sense because the following method is not defined ...
>>>>> __exec_old_SetEqualizerPresetSelection
>>>>
>>>> hm, this is strange. Normally ac++ expands all headers in the woven
>>>> source file, so also the header where class `NConfigDataGUI' is
>>>> defined should be expanded inside Guihelperclasses.cpp, and there a
>>>> proper declaration of __exec_old_SetEqualizerPresetSelection should be
>>>> woven into the class definition. By the way, you are complaining about
>>>> a missing declaration, not a missing definition, do you? In your
>>>> preceeding postings you also posted a definition:
>>>>
>>>> inline void 
>>>> NConfigDataGUI::__exec_old_SetEqualizerPresetSelection(unsigned
>>>> long int value){
>>>>  m_iEqualizerPresetSelection = value;
>>>> }
>>>>  I can only think of two possibilities:
>>>>
>>>> 1. The header containing the definition of class `NConfigDataGUI' is
>>>> somehow not included into the file Guihelperclasses.cpp, but then ac++
>>>> should complain about that. This would be a bug within the parser of
>>>> ac++, that seems pretty improbable to me.
>>>> 2. A bug in the code generation, what in this case seems also quite
>>>> improbable to me.
>>>>
>>>> I must be missing something ... are there any typedefs or macros that
>>>> somehow affect this class?
>>>>
>>>> Maybe Olaf knows more???
>>>>
>>>> Ciao, Fabian
>>>>
>>>> _______________________________________________
>>>> aspectc-user mailing list
>>>> aspectc-user at aspectc.org
>>>> http://www.aspectc.org/mailman/listinfo/aspectc-user
>>>
>>>
>>>
>> 
> 
> 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aspectc.org/pipermail/aspectc-user/attachments/20050915/327f49a5/attachment.html>

More information about the aspectc-user mailing list