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

[Olaf Spinczyk]

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
>>
>>
>>
>