Re: [ros-dev] Autogenerating compiler specific .def files

[Aleksey Bragin]

Marc, I think I haven't been very clear on this. What I mean, is that  
the .spec format already includes *everything* needed to produce  
either gcc or msvc-format .def file. So no point in creating yet  
another format. Nothing more nothing less, that's what I ment.

I'm glad to hear disadvantages of that way.

WBR,
Aleksey Bragin.

On Nov 24, 2007, at 7:01 PM, Marc Piulachs wrote:
> > There is absolutely no need to invent yet another format for storing
> > export functions. It was invented once by MSVC, it was invented by
> > GCC/MinGW, both are incompatible, it was invented by Wine to have
> > ability of easy functions stubbing. Should there be another invention
> > of the same wheel by ReactOS now?
> > If GCC/MinGW wouldn't be that *strange*, it could stdcall-fixup, and
> > then properly link, this way .def could be created in the lowest
> > common denominator format.
>
> That's the problem I'm trying to solve..:) The point on this change  
> is not
> really store them in xml inset of plain text, is not that  
> important, for me
> there are two reasons, first declare this information so rbuild can
> manipulate it as objects and apply checking , logic , whatever ...  
> and the
> most important store the information on a neutral , compiler  
> agnostic and
> rich format that allow us to generate (export to) ANY format we  
> desire out
> of it. Currently def files are tided to mingw which is bad.
>
> At the end the information must be there so what's the difference  
> between
> having it in a file with extension .def or .spec and having it on a  
> file
> with .rbuild extension?  IMO It's not reinventing the wheel
>
> /Marc

[Colin Finck]

Hello,

For your information: As there were no more comments on this, I started
working on a tool now, which transforms .spec files into both GNU and MSVC
.def files.
It will be based a bit on winebuild's code, but won't include all this stuff
we don't need (code generation for non-PE compilers, 16-bit support, etc.),
so it should become more lightweight and faster.

If someone still disagrees with such a solution, please do that now and
explain why.

Regards,

Colin

Aleksey Bragin wrote:
> Marc, I think I haven't been very clear on this. What I mean, 
> is that  
> the .spec format already includes *everything* needed to produce  
> either gcc or msvc-format .def file. So no point in creating yet  
> another format. Nothing more nothing less, that's what I ment.
>
> I'm glad to hear disadvantages of that way.
>
> WBR,
> Aleksey Bragin.

[Marc Piulachs]

Hi Colin,

There is something I still don't see clear, the integration with rbuild.
When we use the tool you are writing with the mingw backend rbuild will
generate the required instructions in the makefile.auto and will be make who
executes it as part of a module compilation, same case as winebuild no
problem here. But when this same tool is used with the MSVC backend will
have to be rbuild who executes it directly as no makefile.auto is generated
in this case. See the problem?

I see 3 possible solutions for it:

- Let MSVC generate the .def file by calling your tool in the pre-build
event. (solution equivalent to the makefile.auto in mingw) it has the
disadvantage of regenerating the def file in every build. Also will require
having the full codebase (your tool included) to build a module with msvc.
- Make it different to winebuild and process all the codebase searching for
.spec files and generate both .def files (gcc and msvc) in the intermediate
folder when called by Makefile in the same sense as buildno or nci tools. It
will be executed only if the files are not present. It's not very elegant.
- Integrate your tool inside rbuild, I'm against adding particular parsers
inside rbuild but we may do an exception here as it seems to me the best
solution.

Or may be you have a better solution.

Regards,
/Marc

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Colin Finck
Sent: Saturday, December 01, 2007 1:40 PM
To: 'ReactOS Development List'
Subject: Re: [ros-dev] Autogenerating compiler specific .def files

Hello,

For your information: As there were no more comments on this, I started
working on a tool now, which transforms .spec files into both GNU and MSVC
.def files.
It will be based a bit on winebuild's code, but won't include all this stuff
we don't need (code generation for non-PE compilers, 16-bit support, etc.),
so it should become more lightweight and faster.

If someone still disagrees with such a solution, please do that now and
explain why.

Regards,

Colin

Aleksey Bragin wrote:
> Marc, I think I haven't been very clear on this. What I mean, 
> is that  
> the .spec format already includes *everything* needed to produce  
> either gcc or msvc-format .def file. So no point in creating yet  
> another format. Nothing more nothing less, that's what I ment.
>
> I'm glad to hear disadvantages of that way.
>
> WBR,
> Aleksey Bragin.

_______________________________________________
Ros-dev mailing list
[e-mail]
http://www.reactos.org/mailman/listinfo/ros-dev

[Magnus Olsen]

Hi
some api need have xxx ineasd for xxx@8 in .def file for gcc
other wise some apps fail found that api. if we look at ms dll file
we can found api without @8 so we need define some api without
@8. This is very few case. but we need think of that

----- Original Message ----- 
From: "Marc Piulachs" [e-mail]
To: "'ReactOS Development List'" [e-mail]
Sent: Saturday, December 01, 2007 4:29 PM
Subject: Re: [ros-dev] Autogenerating compiler specific .def files
> Hi Colin,
>
> There is something I still don't see clear, the integration with rbuild.
> When we use the tool you are writing with the mingw backend rbuild will
> generate the required instructions in the makefile.auto and will be make 
> who
> executes it as part of a module compilation, same case as winebuild no
> problem here. But when this same tool is used with the MSVC backend will
> have to be rbuild who executes it directly as no makefile.auto is 
> generated
> in this case. See the problem?
>
> I see 3 possible solutions for it:
> Let MSVC generate the .def file by calling your tool in the pre-build
>
> event. (solution equivalent to the makefile.auto in mingw) it has the
> disadvantage of regenerating the def file in every build. Also will 
> require
> having the full codebase (your tool included) to build a module with msvc.
> Make it different to winebuild and process all the codebase searching
>
> for
> .spec files and generate both .def files (gcc and msvc) in the 
> intermediate
> folder when called by Makefile in the same sense as buildno or nci tools. 
> It
> will be executed only if the files are not present. It's not very elegant.
> Integrate your tool inside rbuild, I'm against adding particular parsers
>
> inside rbuild but we may do an exception here as it seems to me the best
> solution.
>
> Or may be you have a better solution.
>
> Regards,
> /Marc
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Colin Finck
> Sent: Saturday, December 01, 2007 1:40 PM
> To: 'ReactOS Development List'
> Subject: Re: [ros-dev] Autogenerating compiler specific .def files
>
> Hello,
>
> For your information: As there were no more comments on this, I started
> working on a tool now, which transforms .spec files into both GNU and MSVC
> .def files.
> It will be based a bit on winebuild's code, but won't include all this 
> stuff
> we don't need (code generation for non-PE compilers, 16-bit support, 
> etc.),
> so it should become more lightweight and faster.
>
> If someone still disagrees with such a solution, please do that now and
> explain why.
>
> Regards,
>
> Colin
>
> Aleksey Bragin wrote:
> > Marc, I think I haven't been very clear on this. What I mean,
> > is that
> > the .spec format already includes *everything* needed to produce
> > either gcc or msvc-format .def file. So no point in creating yet
> > another format. Nothing more nothing less, that's what I ment.
> >
> > I'm glad to hear disadvantages of that way.
> >
> > WBR,
> > Aleksey Bragin.
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Steven Edwards]

On Dec 1, 2007 7:39 AM, Colin Finck [e-mail] wrote:
> Hello,
>
> For your information: As there were no more comments on this, I started
> working on a tool now, which transforms .spec files into both GNU and MSVC
> .def files.
> It will be based a bit on winebuild's code, but won't include all this stuff
> we don't need (code generation for non-PE compilers, 16-bit support, etc.),
> so it should become more lightweight and faster.
>
> If someone still disagrees with such a solution, please do that now and
> explain why.

I think you need to add this feature to Winebuild and leave winebuild in
place. The reason why is that winebuild has the ability to create ELF
winelib binaries that are really contain the embedded PE dll. Using winebuild
and the winelib binary format for port to other archtechtures should save
you a lot of problems. I don't know much about the format of arty's work on
PPC but I know winebuild already has the ability to generate PPC and SPARC
winelib ELF binaries and ReactOS already contains an ELF loader. Extending
a few APIs in ReactOS to actually teach it how to load the winelib dlls
should save a lot of headaches because you would not need to hack much
of a customer compiler for the new target platform. The PE target in gcc to my
knowledge only exists still for i386/x86-64 and Arm/Xscale.

Thanks
Steven
-- 
Steven Edwards

"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo

[KJK::Hyperion]

Let me chime in, before you get yourselves in another mess
> For your information: As there were no more comments on this, I started
> working on a tool now, which transforms .spec files into both GNU and MSVC
> .def files.

You _do_ know that Microsoft's linker tools have only limited support
for .def files, right? That you cannot create __stdcall exports without
also exporting the decoration, unless the functions were marked as
__declspec(dllexport)? and that in the latter case it's much easier to
let the linker process the compiled .obj files to extract the dllexport
directives to produce a .exp and a .lib file? hence, that the best way
to produce import/export libraries is to turn the .spec file not into a
.def, but into a .c/.cpp with dummy implementations of each function and
a __declspec(dllexport) attribute, compile it and run the linker on the
generated .obj file? Spare yourself the pain I went through. Think about it