Code::Blocks

User forums => Using Code::Blocks => Topic started by: rcrnstn on July 21, 2009, 02:51:49 am

Title: .def & import library names
Post by: rcrnstn on July 21, 2009, 02:51:49 am
When building "Test.dll" I expect the other files to be named "libTest.def" and "libTest.a".
Instead they are called "libTest.dll.def" and libTest.dll.a". Why is this? Is it by design or am I missing something?

I am basing my project on the "Dynamic Link Library" template.
In "Project Options->Build Targets" I have ticked the "Create import library" and "Create .DEF exports file".
I also have "Auto-generate filename prefix" and "Auto-generate filename extension" ticked. My output filename is Test.dll

For now I have solved the problem by unticking "Create import library" and "Create .DEF exports file" and added
-Wl,--output-def=libTest.def
-Wl,--out-implib=libTest.a
to my "Other Link Options"

I'd appreciate any reply
Title: Re: .def & import library names
Post by: Ceniza on July 25, 2009, 09:21:09 am
I had the exact same complaint to the developer who added that "feature". The reason he added that behavior is that when you want to create an output file which is really a DLL but with another extension and dots in its name (like this.is.evil.plugin), he won't get what he wants. The current behavior works lovely for all cases (according to him). I also think this behavior is 'wrong' (as in 'it is not what one would expect to happen' and 'it is not what one wants to happen'). Although, he is willing to accept a change as long as it also works fine with his scenario. Thing is, no solution has been discussed at all.

The solution would most likely involve adding another checkbox and/or an extra text field (extension?). Ideas are welcomed.
Title: Re: .def & import library names
Post by: johne53 on October 26, 2009, 09:59:35 pm
On the face of it, this would seem to be a simple problem to fix - i.e. if the target DLL has a non-standard extension, append ".dll.a" or ".dll.def" or whatever is appropriate. But if its extension is the standard ".dll" just replace that extension with ".lib", ".a" or ".def". Or even better - allow the user some choice.

In any case, this only seems to be a problem when certain compilers are selected. If it can work sensibly with some compiler selections why can't it be made to work sensibly for the others???
Title: Re: .def & import library names
Post by: MortenMacFly on October 27, 2009, 06:53:56 am
But if its extension is the standard ".dll" just replace that extension with ".lib", ".a" or ".def". Or even better - allow the user some choice.
It's not as easy as that. You have to take into consideration the user's ability to have C::B autogenerate the prefix and extension.

So - Ceniza:
As I am unaware to find what I am looking for... I nned two posts as reference:
1.) The one of TDragon where he explains the required handling with the MinGW/GCC compiler
2.) Your post with a first suggestion about "required checkboxes".
[Edit]: 3.) Not to forget: The SVN revision where this change was introduced. :lol:

Hence where are they??? :?
Title: Re: .def & import library names
Post by: johne53 on October 27, 2009, 08:52:43 am
It's not as easy as that. You have to take into consideration the user's ability to have C::B autogenerate the prefix and extension.

Morten - I don't understand how that complicates the situation. Can you give an example?

My perspective (which admittedly hasn't had much thought put into it) goes something like this:-

1) Regardless of how the target DLL's extension gets generated, it will either be standard or non-standard.
2) If it's non-standard, append ".a" or ".lib" or ".def" (or whatever) when generating the link library and def files.
3) Alternatively, if it's the standard ".dll" or ".so" replace the extension, instead of appending a further extension (or at least offer this as an option).
Title: Re: .def & import library names
Post by: MortenMacFly on October 27, 2009, 09:26:25 am
Morten - I don't understand how that complicates the situation. Can you give an example?
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.
Title: Re: .def & import library names
Post by: Ceniza on October 27, 2009, 08:10:32 pm
What am I supposed to answer? How's it supposed to clarify things? I am lost (and tired).
Title: Re: .def & import library names
Post by: thedmd on February 13, 2010, 11:32:31 pm
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: [Select]
wxString CompileTargetBase::GetDynamicLibImpFilename() const;
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: [Select]
        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);
        }

To:
Code: [Select]
        fname.SetExt(compiler->GetSwitches().libExtension);
Title: Re: .def & import library names
Post by: MortenMacFly on February 14, 2010, 11:30:42 am
To change this anoying behaviour replace:
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.
Title: Re: .def & import library names
Post by: thedmd on February 14, 2010, 12:01:00 pm
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.
Title: Re: .def & import library names
Post by: MortenMacFly on February 14, 2010, 05:40:01 pm
If the user wish he/she can replace $(TargetFileName) with $(TargetName) and we got old behavior.
Look: It is not as simple as this.
If a user selects "App.Plugin" as a library name you don't know if (s)he wants to have a "Ap.Plugin.dll" or really just "App.Plugin". So querying any extension (by using GetExt()) will not work reliable as for a file like "App.Plugin" it will return "Plugin" as extension which is most likely not intended. Ceniza once posted a solution with another checkbox option that would really enable to setup exactly how the file name should look like and TDragon once posted how GCC "expects" the library extensions. However, I don't find these posts anymore, so I asked Ceniza to have a look at his history here:
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.
...but he didn't answer yet. :-(

From my point of view that was the only acceptable solution so far as it allows for any file naming scheme.
Title: Re: .def & import library names
Post by: thedmd on February 14, 2010, 06:02:48 pm
Yep, it is not simple also it is not that hard. I think C::B should allow to choose what user want to got.

Why Set/GetExt are used at the first place for generating target filenames, if CompilerTargetBase is able to provide sufficient information? I found that the name of import library and definition file are computed from target name by using SetExt(). Did I miss something important?
Title: Re: .def & import library names
Post by: johne53 on February 14, 2010, 06:37:25 pm
Look: It is not as simple as this.
If a user selects "App.Plugin" as a library name you don't know if (s)he wants to have a "Ap.Plugin.dll" or really just "App.Plugin".

But there's a check box that allows the user to determine whether or not the extension should be auto-generated. If (s)he checks the box and types "App.Plugin" then (s)he'll get "App.Plugin.dll". If (s)he doesn't check the box there should be an assumption that the typed extension (if there is one) is the intended extension. And if there isn't a typed-in extension, then it does whatever it does now. Really Morten I think you're finding complications where there aren't any.
Title: Re: .def & import library names
Post by: MortenMacFly on February 14, 2010, 07:47:20 pm
Really Morten I think you're finding complications where there aren't any.
Sorry, but I insist that this needs to be implemented correctly. Again: the only correct way I see is the one proposed by Ceniza... wherever that was. But I recall that I made my mind with that suggestion.
Title: Re: .def & import library names
Post by: johne53 on February 14, 2010, 07:52:28 pm
When/where did Ceniza propose something? There's no proposal in this thread AFAICT.
Title: Re: .def & import library names
Post by: MortenMacFly on February 14, 2010, 07:55:10 pm
When/where did Ceniza propose something? There's no proposal in this thread AFAICT.
If it was in this thread I wouldn't ask... I am not that lazy. :lol:

We had that discussion already after the patch was applied in another thread. It got lost on the way as other things were more important to me. However, I cannot find this thread anymore, but it was a fruitful discussion. I think Ceniza just has to look in his history around that time and can pinpoint us easily.
Title: Re: .def & import library names
Post by: johne53 on February 14, 2010, 08:03:59 pm
If it was in this thread I wouldn't ask... I am not that lazy. :lol:

No offence meant...  :)
Title: Re: .def & import library names
Post by: thedmd on February 14, 2010, 09:02:32 pm
Here it is:
When the user wants to create a non-as-common-as-a-plain-.dll-file (like .Plugin),
Notice that this was only *one* problem.

Even worse was if you tried to create a System.Management.DLL file. This did not work, too. And that's the one I was referring to at most. Because such misbehaviour is in fact not acceptable.

What was wrong with System.Management.DLL again? (I have forget only memory)
If I remember right, it was turned int "System.dll" .

Well... with an extension field you should not have that problem.

Output file name: System.Management (user input)
[ ] Use custom extension (unchecked)
Custom extension: dll (default shown, empty, previous value, ...)
Full output file name: System.Management.dll (read-only)
Full import lib file name: libSystem.Management.a (read-only)

Is it too bad an idea?
Title: Re: .def & import library names
Post by: johne53 on February 14, 2010, 10:56:23 pm
There's an obvious problem with that suggestion.... it seems to apply the custom extension even though the option to Use custom extension was left unckecked. To be honest, If you read my suggestion (from a few posts back) and put some thought into it, I really think it's a much more elegant solution.
Title: Re: .def & import library names
Post by: MortenMacFly on February 15, 2010, 06:43:47 am
Here it is:
Exactly! That was it. But now that I read it again I also recall the problem I had with this:
Currently we put the prefix and extension automatically to the name of the library for convenience. But doing that and using Ceniza's suggestion would mean that the extension gets added over and over again... :-(

If you read my suggestion (from a few posts back) and put some thought into it, I really think it's a much more elegant solution.
Do you mean this one:
Import library: $(OutDir)$(TargetFileName)$(DefaultImportExtension)
???

Here the problem is: What if a user puts "foo.dll" in the target name field? Would it become foo.dll.a and foo.dll.dll then? If so then I can tell you that we will get "bug reports" on that issue.
Title: Re: .def & import library names
Post by: johne53 on February 15, 2010, 07:25:16 am
No, I meant this suggestion....

But there's a check box that allows the user to determine whether or not the extension should be auto-generated. If (s)he checks the box and types "App.Plugin" then (s)he'll get "App.Plugin.dll". If (s)he doesn't check the box there should be an assumption that the typed extension (if there is one) is the intended extension.

If the user types in "foo.dll" amd also checks the box, no further extension would be added (to the dll) because the functionality should be intelligent enough to realise that the extension is already the one that would have been auto-generated. This is the same scenario as if the user had only typed in "foo" (I think... it's quite some time since I looked at what happens if no extension is given but the box is also left unchecked. I might be wrong about that). However, whether I'm right or wrong about the dll naming, any associated files would be called "foo.lib", "foo.def", foo.a" or whatever is appropriate.

However, if the user types in "foo.plugin" and selects auto-generation for the extension, the resulting libraries will be  "foo.plugin.dll", "foo.plugin.lib", "foo.plugin.def", "foo.plugin.a" or whatever.

Final scenario - if the user types in "foo.plugin" but doesn't select auto-generation (for the extension) the resulting libraries will be  "foo.plugin", "foo.lib", "foo.def", "foo.a" etc.

Hope that makes sense.
Title: Re: .def & import library names
Post by: thedmd on February 15, 2010, 10:35:58 am
Every suggestion I had encountered there stands for "what if user want...". My idea is quite simple, instead of army of checkboxes let the user type in name prototype.

Output filename:
foobar
Import library filename:
$(TargetName)
Definition file filename:
$(TargetName)
[X]
Auto-generate filename prefix
[X]
Auto-generate filename extension

Output filename
   Auto-prefix    
   Auto-ext    
GCC
DLL
GCC
LIB
GCC
DEF
VC++
DLL
VC++
LIB
VC++
DEF
    foobar    
    X    
    X    
    foobar.dll         libfoobar.a         libfoobar.def         foobar.dll         foobar.lib         foobar.def    
    foobar.dll    
    X    
    X    
    foobar.dll         libfoobar.a         libfoobar.def         foobar.dll         foobar.lib         foobar.def    
    foo.bar    
    X    
    X    
    foo.bar.dll         libfoo.bar.a         libfoo.bar.def         foo.bar.dll         foo.bar.lib         foo.bar.def    
    foo.bar.dll    
    X    
    X    
    foo.bar.dll         libfoo.bar.a         libfoo.bar.def         foo.bar.dll         foo.bar.lib         foo.bar.def    
    foobar              
    X    
    foobar.dll         foobar.a         foobar.def         foobar.dll         foobar.lib         foobar.def    
    foobar.dll              
    X    
    foobar.dll         foobar.a         foobar.def         foobar.dll         foobar.lib         foobar.def    
    foo.bar              
    X    
    foo.bar.dll         foo.bar.a         foo.bar.def         foo.bar.dll         foo.bar.lib         foo.bar.def    
    foo.bar.dll              
    X    
    foo.bar.dll         foo.bar.a         foo.bar.def         foo.bar.dll         foo.bar.lib         foo.bar.def    
    foobar    
    X    
              foobar         libfoobar         libfoobar         foobar         foobar         foobar    
    foobar.dll    
    X    
              foobar.dll         libfoobar         libfoobar         foobar.dll         foobar         foobar    
    foo.bar    
    X    
              foo.bar         libfoo.bar         libfoo.bar         foo.bar         foo.bar         foo.bar    
    foo.bar.dll    
    X    
              foo.bar.dll         libfoo.bar         libfoo.bar         foo.bar.dll         foo.bar         foo.bar    
    foobar                             foobar         foobar         foobar         foobar         foobar         foobar    
    foobar.dll                             foobar.dll         foobar         foobar         foobar.dll         foobar         foobar    
    foo.bar                             foo.bar         foo.bar         foo.bar         foo.bar         foo.bar         foo.bar    
    foo.bar.dll                             foo.bar.dll         foo.bar         foo.bar         foo.bar.dll         foo.bar         foo.bar    

Replace import library filename with $(TargetFileName) and we got:
Target name
Target file name
   Auto-prefix    
   Auto-ext    
GCC
LIB
VC++
LIB
    foobar         foobar.dll    
    X    
    X    
    libfoobar.dll.a         foobar.dll.lib    
    foobar.dll         foobar.dll    
    X    
    X    
    libfoobar.dll.a         foobar.dll.lib    
    foo.bar         foo.bar.dll    
    X    
    X    
    libfoo.bar.dll.a         foo.bar.dll.lib    
    foo.bar.dll         foo.bar.dll    
    X    
    X    
    libfoo.bar.dll.a         foo.bar.dll.lib    
    foobar         foobar.dll              
    X    
    foobar.dll.a         foobar.dll.lib    
    foobar.dll         foobar.dll              
    X    
    foobar.dll.a         foobar.dll.lib    
    foo.bar         foo.bar.dll              
    X    
    foo.bar.dll.a         foo.bar.dll.lib    
    foo.bar.dll         foo.bar.dll              
    X    
    foo.bar.dll.a         foo.bar.dll.lib    
    foobar         foobar    
    X    
              libfoobar         foobar    
    foobar.dll         foobar.dll    
    X    
              libfoobar.dll         foobar.dll    
    foo.bar         foo.bar    
    X    
              libfoo.bar         foo.bar    
    foo.bar.dll         foo.bar.dll    
    X    
              libfoo.bar.dll         foo.bar.dll    
    foobar         foobar                             foobar         foobar    
    foobar.dll         foobar.dll                             foobar.dll         foobar.dll    
    foo.bar         foo.bar                             foo.bar         foo.bar    
    foo.bar.dll         foo.bar.dll                             foo.bar.dll         foo.bar.dll    

$(TargetName) - file name without extension (default extension is always stripped, .dll for examle)
$(TargetFileName) - file name with extension (if auto-ext is checked and ext is different from default one, ext is appended)

Is it sufficient?
Title: Re: .def & import library names
Post by: MortenMacFly on February 15, 2010, 11:41:37 am
Is it sufficient?
I guess so... :lol:
Title: Re: .def & import library names
Post by: thedmd on February 15, 2010, 11:54:16 am
Do you agree to implement this solution in C::B? It is rather simple. I'm not sure where those changes have to be introduced, becouse I allready found a few places where the target name is computed.
Title: Re: .def & import library names
Post by: thedmd on February 18, 2010, 04:52:24 am
BUMP
Title: Re: .def & import library names
Post by: Seronis on February 18, 2010, 05:09:12 am
dont bump threads unless you are adding more to the discussion.
Title: Re: .def & import library names
Post by: MortenMacFly on February 18, 2010, 07:16:38 am
Do you agree to implement this solution in C::B?
What did I say:
Is it sufficient?
I guess so... :lol:
???

I am awaiting a patch accordingly.
Title: Re: .def & import library names
Post by: thedmd on February 18, 2010, 08:12:05 am
I have bumped this thread since I don’t believe discussion is over. Yes, we agree to that solution, but this don’t close the topic. Nothing was said about possible implementation details.

I had asked Morten if he is willing to implement this feature, because I believe he is best for this job. My changes may hit parts of C::B that I’m unaware of and my knowledge about C::B source code is very limited at the moment.

I believe “I guess so...” don’t carry the information: “This is a reasonable solution, please prepare a patch so we can be able to test it and give you a feedback.”. I’s tempting to place here some smiling emoticon, but I’m trying to avoid them for a while now, so you can read this comment instead.

I still have one question unanswered. Why target name is computed in more than one place in C::B? This information will be definitely helpful.

P.S. In case of doubts, please look at the left side of this post.
Title: Re: .def & import library names
Post by: MortenMacFly on February 18, 2010, 09:21:08 am
I had asked Morten if he is willing to implement this feature, because I believe he is best for this job.
I don't exactly recall this question, but I guess it'll take time then. I am quite busy atm and in addition I won't start with work on something that works but doesn't look nice. Other things that really don't work have a higher priority for me.

I think this discussion lead to a proposal how to do it. Now it's time to get the hands on. But this is really nothing hard to do, most work comes with testing every combination I guess. So I am hereby asking for volunteers - it's a nice and easy job to do, just right for people that want to help with C::B development and are just at the beginning.

Just start in compilercommandgenerator.cpp, method:
Code: [Select]
wxString CompilerCommandGenerator::SetupOutputFilenames(Compiler* compiler, ProjectBuildTarget* target)
The other places should not be of interest.
Title: Re: .def & import library names
Post by: thedmd on February 18, 2010, 09:36:29 am
My earlier question may be misinterpreted. I see that it can be missed.

In my opinion we have a problem and we need to solve it, not just discuss. Now we know what each other thinking about this. We finally agreed to solve the issue and topic is going to be closed. Nice and smooth.

I will try to prepare appropriate patch soon. Thanks for hint, it will be helpful.
Title: Re: .def & import library names
Post by: thedmd on February 24, 2010, 01:36:08 pm
Done. Patch can be found here (http://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=2937&group_id=5358).

Two new fileds were added with following default values:
Import library filename:
$(TARGET_OUTPUT_DIR)$(TARGET_OUTPUT_BASENAME)
Definition file filename:
$(TARGET_OUTPUT_DIR)$(TARGET_OUTPUT_BASENAME)

One macro has been added: $(TARGET_OUTPUT_FILENAME) which is filename with extension but without path. Use this in above fields to obtain "old" behaviour (from foobar.dll you will got libfoobar.dll.a).

A word of comment. Current C::B build system is working but it is messy. Several features are implemented more than once in various places, for example adding prefixes and extensions. It is a perfect candidate for refactoring.