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.
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?Please wait until Ceniza answers. This will clarify things.
wxString CompileTargetBase::GetDynamicLibImpFilename() const;
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);
}
fname.SetExt(compiler->GetSwitches().libExtension);
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.
Macro | Windows | Linux |
$(OutputDir) | C:\Project\foobar-0.0.1\ | \home\project\foobar-0.0.1\ |
$(TargetName) | foobar | foobar |
$(TargetFileName) | foobar.dll | foobar.so |
$(DefaultImportExtension) | .lib | .a |
If the user wish he/she can replace $(TargetFileName) with $(TargetName) and we got old behavior.Look: It is not as simple as this.
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. :-(
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".
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.
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:
If it was in this thread I wouldn't ask... I am not that lazy. :lol:
If I remember right, it was turned int "System.dll" .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)
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?
Here it is:Exactly! That was it. But now that I read it again I also recall the problem I had with this:
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)???
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.
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 |
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 |
Is it sufficient?I guess so... :lol:
Do you agree to implement this solution in C::B?What did I say:
???Is it sufficient?I guess so... :lol:
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.
wxString CompilerCommandGenerator::SetupOutputFilenames(Compiler* compiler, ProjectBuildTarget* target)
Import library filename: | $(TARGET_OUTPUT_DIR)$(TARGET_OUTPUT_BASENAME) |
Definition file filename: | $(TARGET_OUTPUT_DIR)$(TARGET_OUTPUT_BASENAME) |