OT: on IDEs and code writing on steroids

Yigal Chripun yigal100 at gmail.com
Mon May 25 23:13:07 PDT 2009


BCS wrote:
> Reply to Yigal,
> 
>> BCS wrote:
>>
>>> Hello Yigal,
>>>
>>>> C# assemblies are analogous to C/C++/D libs.
>>>> you can't create a standalone executable in D just by parsing the D
>>>> source files (for all the imports) if you need to link in external
>>>> libs.
>>>> you need to at least specify the lib name if it's on the linker's
>>>> search path or provide the full path otherwise.
>>> pagma(lib, ...); //?
>>>
>> that's a compiler directive. nothing prevents a C# compiler to
>> implement this. In general though this is a bad idea. why would you
>> want to embed such outside data inside your code?
> 
> Because it's needed to build the code
> 
>> info needed for building your task should not be part of the code.
> 
> IMO it should. Ideally it should be available in the code in a form 
> tools can read. At a minimum, it should be in the comment header. The 
> only other choice is placing it outside your code and we have already 
> covered why I think that is a bad idea.
> 
>> what if I want to rename the lib,
> 
> So you rename the lib and whatever references to it (inside the code or 
> outside) end up needing to be update. Regardless, you will need to 
> update something by hand or have a tool do it for you. I see nothing 
> harder about updateing it in the code than outside the code.
> 
>> do I have to recompile everything?
> 
> Nope. pragma(lib, ...) just passes a static lib to the linker and 
> doesn't have any effect at runtime. (if you are dealing with .dll/.so 
> libraries then you link in a export .lib with a pragma or load them 
> manually and don't even worry about it at all)
> 
>> what if I don't have the source?
> 
> It's pointing at a static library so source doesn't matter. If you are 
> working from source then you don't need the pragma and what matters is 
> DMD's import path (if it is an unrelated code tree in which cases the 
> path can be developer specific and needs to be set up per system).
> 
>> what if I want to change the version?
> 
> In that case you change the pragma. (again assuming static libs and the 
> same side note for dynamic libs)
> 
>> what if I want to switch a vendor for this lib?
> 
> I have never heard of this being possible without major changes in the 
> calling code so it don't matter.
> 
> 

What I was trying to say is that you're hardcoding the lib name and 
version inside the code. I see two problems with this: if the pragma is 
in my code than I need to re-compile my code if I want to edit the 
pragma (rename lib, change version, change vendor, etc...)
if the pragma is in some 3rd party component which I don't have the 
source for than I can't change the pragma.
either way, it conflicts with my work-flow and goals.

I do not wish to recompile a 1.5GB standalone executable if I just 
changed a minor version of a lib.

IIRC, the math lib in C/C++ comes in three flavors so you can choose 
your trade-off (speed or accuracy) and the only thing you need to do is 
just link the flavor you want in your executable.

you seem keen on combining the build process with compilation which is 
in my experience a very bad thing. it may simplify your life for your 
small projects but as I was telling you before it's a pain in the neck 
for the scale of projects I work on. I don't get why you refuse to see 
that.
what you suggest is _not_ a good solution for me.



More information about the Digitalmars-d mailing list