Compiling module in default package generates new folder

[GoogleCodeExporter]

Create a simple 'Hello world!' example and name it Hello.tart

Compiling the source with

tartc -sourcepath <pwd> -i <tart library path> Hello.tart

results in the error message

error: Error opening output file 'Hello.bc'10

and the creation of a folder named Hello.bc in the current directory.

The problem lies in CodeGen::outputModule(), which does not regard the case of 
a default package.
The attached patch fixes the problem.

(If I misunderstand the tart language and the default package is not supported 
then a sensible error message should be generated.)

Thanks for your support.

Original issue reported on code.google.com by kai.na...@gmail.com on 13 Oct 2010 at 6:44

Attachments:

• CodeGen.cpp.diff

[GoogleCodeExporter]

Original comment by viri...@gmail.com on 13 Oct 2010 at 7:17

• Changed state: Accepted
• Added labels: Component-Compiler, OpSys-All, Priority-Medium, Type-Defect

[GoogleCodeExporter]

Sorry to take so long to get back to this issue. I've been working on a lot of 
other stuff.

I've applied your patch. I also spent about 2 days fixing a lot of other issues 
related to Visual Studio 2010 Express. This includes re-writing the inline 
assembly for the stack crawler, supporting Win32 thread local variables, fixing 
various build issues, and so on.

Unfortunately, I have not been able to actually get a successful build. One 
problem appears to be related to the CMake generation of the project files for 
the stdlib tests - when I attempt to load the CMake-generated solution file 
into MSVC, it prints out a whole bunch of warnings of the following form:

C:\Users\Talin\Projects\tart-build\test\stdlib\ArithmeticOperatorTest.exe.vcxpro
j : error  : The item "ArithmeticOperatorTest.obj" already exists under the 
filter "".

In addition, when I attempt to build the stdlib test, I get errors that look 
like this:

1>------ Build started: Project: ArrayListTest.exe.run, Configuration: Debug 
Win32 ------
1>  '.\ArrayListTest.exe' is not recognized as an internal or external command,
1>  operable program or batch file.
1>  The system cannot find the batch label specified - VCReportError
1>C:\Program 
Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error 
MSB6006: "cmd.exe" exited with code 1.
========== Build: 0 succeeded, 1 failed, 10 up-to-date, 0 skipped ==========

Unfortunately, I have not been able to determine the cause of these problems.

I should also note that a lot has changed in the last several months, some of 
which has an impact on building Tart under MSVC. Tart now supports the option 
to use the LLVM tools to link Tart programs rather than using tartln. This is 
currently the default behavior as configured in the CMake files, although the 
old behavior is still there (although it may be broken at the moment.) My 
reason for doing this is that it's a lot easier to debug problems in linking if 
I am using mostly standard components.

In order for Tart to use the standard LLVM tools, certain parts of tartln have 
been converted into LLVM-compatible dynamically-loadable plugins. That means 
that the Tart build files are now building shared libraries, something that was 
not true before. While I have not had too much problem working with .so files 
under Unix, I'm not certain if there will be problems working with .dll files 
under windows. I've not been able to test this under Windows, since the build 
breakage described above occurs before this point in the build process.

I'm mentioning all of this just so you'll be warned if you feel like checking 
out Tart again :)

Original comment by viri...@gmail.com on 21 Nov 2010 at 2:10

[GoogleCodeExporter]

Hi!

First a thank you for your work. The compilation process is really smoother 
under Windows now.

I currently don't use Visual Studio. I build Tart from the command line 
(msbuild ALL_BUILD.vcxproj). This works fine for me. But I know the message. 
Something similar is shown if you open LLVM in Visual Studio. I did not 
investigate the problem.

LLVM currently does not support dynamically loaded plug-ins under Windows. The 
plug-in is loaded, but the LLVM tools and the plug-in are both statically 
linked against the LLVM libraries. The hook to register a plug-in is therefore 
not executed in the context of the LLVM tool. The problem should go away if it 
would be possible to build DLLs from the LLVM libraries. I suspect that this is 
a problem because you have to specify what to export from a DLL... 

Original comment by kai.na...@gmail.com on 7 Dec 2010 at 6:07

[GoogleCodeExporter]

By the way, are you interested in joining the tart-dev mailing list? Traffic on 
the list is very low, approximately one message per week. If you give me your 
email address, I can add you directly, or you can go to the list page at 
http://groups.google.com/group/tart-dev.

Original comment by viri...@gmail.com on 23 Jan 2011 at 1:00

[GoogleCodeExporter]

Original comment by viri...@gmail.com on 9 Mar 2011 at 11:15

• Changed state: Fixed