User forums > Using Code::Blocks

.def & import library names

<< < (2/7) > >>

MortenMacFly:

--- Quote from: johne53 on October 27, 2009, 08:52:43 am ---Morten - I don't understand how that complicates the situation. Can you give an example?

--- End quote ---
Please wait until Ceniza answers. This will clarify things.
Basically the "bug" is in wxWidgets. We use wx functions to obtain the extension of a file. If you do that on a file like "System.Core.Dll" you get ".Dll". But if you do it on "System.Core" you get ".Core" as an extension! To make things even more complicated think about "App.Paint.Plugin" which shall actually be a DLL but with a different extension. So how would you differ (taking into account that the user has triggered "auto extension on") whether this is the real extension the user wants or not?
Ceniza once proposed a good UI way how to handle this. TDragon proposed how to "tell" the MinGW/GCC compiler what to do. We can continue the discussion once we re-collected this information.

Ceniza:
What am I supposed to answer? How's it supposed to clarify things? I am lost (and tired).

thedmd:
You can restore old behaviour by applying path included bellow. I must note that it is a hack and should not be used without a reason. Since there is no alternative for this moment it is acceptable.

My proposition is simple: add to build system functions that are responsible for returning names of import library and definition file.


--- Code: ---wxString CompileTargetBase::GetDynamicLibImpFilename() const;
--- End code ---

There is a thing that I cannot understand. If CompileTargetBase class contain functions for building target names, why CompilerCommandGenerator don't use them?



Not it is time to path:

Revision: 5480

To change this anoying behaviour replace:

--- Code: ---        wxString current_ext   = fname.GetExt();
        wxString requested_ext = compiler->GetSwitches().libExtension;
        if      (   (platform::windows && !current_ext.IsSameAs(requested_ext, false))
                 || (!current_ext.IsSameAs(requested_ext)) )
        {
            // Note: Do not use SetExt here to handle libs like e.g. System.Core correctly.
            // Otherwise SetExt would result in System.dll instead of System.Core.dll
            fname.SetFullName(fname.GetFullName()+wxFILE_SEP_EXT+requested_ext);
        }
--- End code ---

To:

--- Code: ---        fname.SetExt(compiler->GetSwitches().libExtension);
--- End code ---

MortenMacFly:

--- Quote from: thedmd on February 13, 2010, 11:32:31 pm ---To change this anoying behaviour replace:

--- End quote ---
Keep in mind that this also re-introduces the bug mentioned in the comment. So you won't be able to create certain library files anymore that follow a different naming scheme.

I still believe the current behavior is more correct as it is not a bug.

thedmd:
I agree with you. Current behavior is safer for multiplatform libraries, but have one big disadvantage: violate the standard.

I wish to see additional text field which allow to type in name of import library. That will be sufficient. Example for hypothetical project “FooBar”:

Import library: $(OutDir)$(TargetFileName)$(DefaultImportExtension)

Where:
MacroWindowsLinux$(OutputDir)C:\Project\foobar-0.0.1\\home\project\foobar-0.0.1\$(TargetName)foobarfoobar$(TargetFileName)foobar.dllfoobar.so$(DefaultImportExtension).lib.a
If the user wish he/she can replace $(TargetFileName) with $(TargetName) and we got old behavior.

It this good enough idea to be introduced into C::B? I propose same operation for .def files.

Navigation

[0] Message Index

[#] Next page

[*] Previous page